Version number change? about chocolateygui HOT 17 CLOSED

we are still with 0.11.0 would moving to semver be possible? It thought it was major.minor.revision.build.

from chocolateygui.

From what I understand, what we are using just now is valid.

Each commit to the Git repo will be an increment on the patch/revision number, and we will take ownership of the minor release number using tags on the Git repo to indicate the current major/minor release.

We are not currently including the build number, and I am not sure that we should. Not that we ever will likely need it, but Chocolatey have adopted the standard of using the build number (using a date) to release a new version of the package when something needs changing, that doesn't actually affect the version of the installed application.

Thoughts?

from chocolateygui.

As long as you don't use the third 'dot' (or 4th version number in the MSDN-style versioning scheme), you don't risk breaking upgrade path if you decide to use full SemVer. Note that NuGet doesn't support the SemVer '+' notation for builds (yet), and pre-releases don't support build notations at all currently.

At MyGet, we'll try to faciltitate the auto-increment for you and make it available in the UI as well as through MSBuild properties made available to you.

from chocolateygui.

FYI, you can find my reasoning in the following MSDN article as well: http://msdn.microsoft.com/en-us/magazine/jj851071.aspx.

from chocolateygui.

There is some more information on this topic here:

http://xavierdecoster.com/nuget-package-analysis-encouraging-semantic-versioning

So, on this note then, what defines a patch/revision? Currently, any commit that happens to the git repo increasing the patch/revision number (hence why we are now at ChocolateyGUI 0.11.43-pre). Is this wrong? Should the patch/build number only be incremented when we initiate a build? Depending on how we setup the GitHub hook, surely these things are one in the same thing?

Sorry if this is a naive question, just want to make sure that I am on the right page.

Thanks!

from chocolateygui.

In theory, only a single digit increment can happen between two subsequent releases, whether that be the major, minor or patch version number. Even when applying two (or fourty-two) major changes to the API within a single release, the major version number would increment only by one, whilst all lower version parts would be reset to zero.

As long as you are working in pre-release mode, the SemVer numbers aren't final for the next release. That's why a UI is needed for people to take control of the "semantic" part.

Source commits should not auto-modify the semantics of a version (unless you can automate semantic changes detection on your API). A build number is needed and should be managed by the build agent.

That's the theoretic side of the SemVer guidelines. The trouble comes currently from NuGet not adhering to the full specification. That's also why, in my posts/articles, I always apply the "auto-incrementing pre-release" hack. It's the only "semantically correct" way of not breaking any upgrade path between CI pre-releases and releases. That version format looks like:

{major}.{minor}.{patch}-{prereleaseTag}{buildstamp}

So the {buildstamp} is actually part of the pre-release tag :)

{buildstamp} could be a set of leading zeros + auto-incrementing digit(s), e.g. -CI00001, -CI00002, ... -CI00010, ...
mind the decrement of leading zeros as the auto-incrementing number increases in digits

Besides a simple auto-increment, you could also be using an always-increasing date-time based number, e.g.

string.Format("{major}.{minor}.{patch}-{prereleaseTag}{0}{1}{2}", (utcNow.Year - 2010), utcNow.ToString("MMdd"), utcNow.ToString("CIHHmmss"))

This is close to what MyGet is currently applying if we need to take care of auto-versioning. Improvements & customization to this are on their way to deployment and can be expected soonish. You'll be provided with MSBuild properties that contain the build agent's build stamp (so you can use it in your own scripts) and you'll get a UI to modify the build source's version.

from chocolateygui.

Ah, gotcha.

So currently, rather than having my build script increment the patch number, I could have the number of commits to the repo be the buildstamp, or as you say, use the time and date.

Personally, I think I like the idea of taking the information from the repo (in the absence of some other persisted number on the build server), that way, the information is readily available in the repo, without the need to include some form of version.txt in source control.

Gary

from chocolateygui.

You could define a $(Version) MSBuild variable or something and append one of the provided build stamps, and pass it on to the nuget pack command using the -version switch. That way, the Semantic Version is defined somewhere in your scripts, and the buildstamp is simply seeded into it if available.

from chocolateygui.

Ok, not sure if I follow that part. Where would the MSBuild variable be persisted. Gave you got any examples of this approach?

from chocolateygui.

Ok, forget about MSBuild :) There must be a better way. Are you targeting the project file or a nuspec during packaging?

from chocolateygui.

I just took a look at the build scripts. The environment variables that MyGet will provide you could be passed to the powershell scripts in your build.bat, so you could use them the way you want. Both SemVer and buildstamp will be provided. Persisted buildstamps is coming, and a UI to control it as well.
You can then decide what to use and how you use it :)

from chocolateygui.

Ooo, that sounds very interesting! Really looking forward to the next release of MyGet!

from chocolateygui.

Xavier,

How is it planned that these variables, the build counter and build number format, are going to make it to the build script? Are they going to be passed in as arguments to the build.bat file, and then it is up to the creator of the build script whether they are used or not?

So to recap (for my own understanding more than anything else)...

We are aiming to release version 0.11.0 of ChocolateyGUI. We are still working on this release, but since we have "reset" the version number, this is the planned release version. Since we are still working on it, we are doing a number of commits into the repo (and let's say for the sake of argument, each commit results in a build). What we could have is the following version number:

0.11.0.73 (where 73 is the number of builds that have happened)

Since the inclusion of the revision number isn't SemVer compliant, this isn't a recommended way of doing it.

What we should be doing is something like this:

0.11.0-pre0073

as the version number for the Chocolatey Package. Is that right? Then, when we push to the upstream source, what gets released into the wild is 0.11.0. Within MyGet, as I right in saying that it will strip off the number after the pre tag as well?

Am I also right in saying that the version number that we allocate to the AssemblyInfo.cs and WiX project should still be 0.11.0.73, so that we can identify the binaries within the package? Personally, I think this should be the case, but looking for opinions.

Thanks

Gary

from chocolateygui.

That's right, exactly what I'm suggesting. You'll have access to a set of environment variables, blog post and deployment pending, so more details soon :)

from chocolateygui.

That looks ok to me.

from chocolateygui.

Woot! I will make the necessary modifications to the build script for now (just using the tags in the GitHub repo) and then once we have access to information from MyGet, I will change the build script to use that information. Thanks for all the help Xavier, looking forward to giving this a try on new roll out.

from chocolateygui.

Done :-)

from chocolateygui.