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
Generate file version, remove Common.props #813
Conversation
f842c74
to
142d445
Compare
142d445
to
879d68d
Compare
After that we just need to remove the beta from the suffix to make it a stable release? |
That's the technical version. Are we sure that the public API as great as it can get? I'd make sure that there's nothing eerily possibly to hurt us by needing to support. |
What I meant was purely technical, not assuming taht we go stable once the Pr is merged. Just to know what the actions are to effectively have a stable version number. |
Yes the version number 3.0.0.0 is just for binding. When we git RTM NuGet package is 3.0.0 with file version of say.. 3.0.0.345, assembly version 3.0.0. Next should be NuGet: 3.0.1, FileVersion: 3.0.1.456, Assembly: 3.0.1.0 . Or that just my thinking.
|
So a stable release means always setting the version manually with the commit, right? |
Yes, until there's some GitVersion or similar to help / sniffing the tag, like if tag matches "vX.Y.Z" and we are in master, extract numerical value and use it. |
Can GitHub actions have parameters, like with a custom form? that would ask for the version number, and we wouldn't have to commit it in code. |
Actually a custom tag syntax might be the best. So if a tag is added to the release/3.x branch, we can then ensure it starts with 3.x.y.z and publish the package. |
I do something similar in Quartz. So if no tag suffix is preview and otherwise trust in code. Would probably be better to just pass the tag as Version like you suggested. Can we merge this in interim? |
merge |
Now NuGet package version still the same as before (containing beta), file version is 3.0.0.BuildVersion, assembly version is 3.0.0.0 (no binding redirects).
fixes #492