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

Remove weird BuildVersionNumber formatting #11

Closed
dazinator opened this issue May 2, 2015 · 0 comments
Closed

Remove weird BuildVersionNumber formatting #11

dazinator opened this issue May 2, 2015 · 0 comments
Assignees
Labels

Comments

@dazinator
Copy link
Owner

When passing in the msbuild property /p:BuildVersionNumber - this number is appended to the version number in your module's manifest file, to produce the version Number for the NuGet package that is produced for your module.

The idea is, that you can pass in an incrementing number, from a build server for example, and the NuGet deployment packages that are produced will automatically have an incremented version number, even if a developer has forgotten to update the version in the module's manifest file. This ensures each build generates uniquely identifiable deployment packages that can be traced back to said build.

However, there is some logic currently that treats this property as a cruise control build number i.e 1.0.12345.A
and reformats it to extract the 5 digit changeset number - i.e the 12345.

This is all specific to Cruise Control and needs to be removed.

Remove this formatting logic, and honour the build number passed in.

This does mean that people will have to pass in a number that is valid when appended to the version number in their modules manifest, for a NuGet package version number.

Dnn version numbers are max 3 digit, so the typical scenario would be to use 3 digit version numbers on the dnn manifest file, and then an integer value for the build number - which would produce a 4 digit numbered NuGet package, where the last digit is the build number.

@dazinator dazinator added the bug label May 2, 2015
@dazinator dazinator self-assigned this May 2, 2015
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

1 participant