Comments (17)
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.
Related Issues (20)
- Provide ability to use option for Chocolatey CLI commands to skip cached HTTP query results HOT 1
- Unexpected output in Console and Log
- Allow default sort order to be a setting in Chocolatey GUI
- Exit code 1603 when trying to install chocolateygui 1.1.0 HOT 3
- Exit code 1603 when trying to install chocolateygui 1.1.0 HOT 11
- Configure Chocolatey GUI to prompt for repository credentials like the Choco CLI HOT 1
- Unhandled Exception with GUI despite multiple un- and re-installs HOT 4
- Provide a way to ignore HttpCache when retrieving packages
- Make the package view for remote sources and This PC source consistent
- Add feature to automatically refresh the view on install, upgrade, reinstall or uninstall
- Add clearer messaging when downgrading a package HOT 1
- Failed to start application. HOT 6
- Related to #112 HOT 1
- Changes to Queries for the Chocolatey Community Repository
- COMException HRESULT 0x80072EE4 when trying to view __some__ package's details HOT 11
- Replace console view with log capture and view
- Raise minimum Chocolatey.lib/Chocolatey CLI version to 2.2.0 or greater
- Error while running chocolateyInstall.ps1 HOT 4
- More than 20 software titles on the Chocolatey GUI
- Ability to hide installed items in "chocolatey" tab HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chocolateygui.