Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommended version number scheme for SDK? #2314

Closed
riezebosch opened this issue Feb 14, 2019 · 8 comments
Closed

Recommended version number scheme for SDK? #2314

riezebosch opened this issue Feb 14, 2019 · 8 comments
Assignees
Labels

Comments

@riezebosch
Copy link

For maintainting the dotnetcore-chocolateypackages I want to add 3.0-preview but I'm not sure what version for the SDK currently is recommended.

The SDK version from the releases.json is not semver and the latest-release tend to be aligned with the runtime and not the SDK.

Should I be using the 3.0-preview2 for now and switch to runtime & sdk specific versions when out of preview? Or is the latest-release version the way forward and encapsulates this underlying versions?

Any advice on this?

@leecow
Copy link
Member

leecow commented Feb 15, 2019

We're in the process of standing up release branches which would make sense for you to follow. For the sdk, picking up the latest from release/3.0.1xx should do the trick.

@livarcocc to confirm.

@riezebosch
Copy link
Author

Got it. But what about the aspnetcore-runtime and windows-hosting? Should it be 3.0.0-preview2? Because there are already multiple 3.0.0-preview releases that only differ in last part (which doesn't fit into semver).

@leecow
Copy link
Member

leecow commented Feb 22, 2019

All components should be picking up the *-preview{n}-{buildnumber} scheme.

@riezebosch
Copy link
Author

But the {buildnumber} part is breaking semver and the *-preview part seems not unique.

@karelz
Copy link
Member

karelz commented Feb 27, 2019

Why is the {buildnumber} part breaking semver? It seems complaint to me according to: https://semver.org/#spec-item-9

That said, I don't think we claimed we follow semver, although it would be nice ...

@riezebosch
Copy link
Author

My point is that translating the version from the releases.json into something that is unique and supported by chocolatey is or might be a problem. It seems to work now for creating packages but I'm not sure yet if it can be published in that format.

 dotnetcore-sdk.3.0.100-preview-010184.nupkg

@leecow
Copy link
Member

leecow commented Feb 28, 2019

I would think that's OK (no "." in the prerelease string)?

We're in the process of finishing up Preview 3 (hopefully out Tuesday) and the SDK version will look like 3.0.100-preview3-010402 (not finale, just an example from the current build).

@riezebosch
Copy link
Author

Okay, it looks like it's possible: https://chocolatey.org/packages/dotnetcore-runtime.install/3.0.0-preview-27324-5 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants