Hi James, Thanks for your feedback.
1st, I should have discussed this earlier. If there was more discussion time, I might have gone with version numbering like 4.0.3.0.0, 4.0.3.0.1 and 4.0.3.0.2 for all Windows hotfixes/builds for 4.0.3.0. I've only ever released 1 "hotfix". It was released because there was 1 single commit from the next version that needed to be included, and it was Windows specific. IIRC, it would have been too much work to release a new version for all platforms. Usually a new version, even if it is a 4th digit update, has dozens of commits. I will proceed with using the date for 4.0.3.0. I will release 4.0.3.0-20141021. As you point out, consistency is important. -Mike#2 On Mon, Oct 20, 2014 at 8:27 AM, James M. Pulver <[email protected]> wrote: > Personally, I don't love either build numbering method. That said, I find the > date suffix much harder to parse personally, it's too many numbers munged > together and I just end up ignoring it. > > What do you all mean by the numbering anyway - i.e. why would > 4.0.3.0+hotfix1 > Not be 4.0.3.1? > > Personally, from a Windows admin / user perspective, I don't care what the > build process is in terms of a binary I download. I care if something changed. > > So if 4.0.3.0+build1 changed the version of gcc but didn't change the output, > I doubt anyone would care - maybe somewhere would be a build # for deep > debugging, but it wouldn't be in any download name someone would use. > > If 4.0.3.0+build2 packaged a new library that fixed a bug, I'd expect to see > 4.0.3.1 again as it fixed something "in the product" from my perspective. > > I'm a fan of MajorChange.MinorFeatureChange.Bugfix.someotherchange sort of > software numbering. > > That all said - I would like to see the numbering be consistent across > platforms in terms of code that is shared, and the method also be consistent. > -- > James Pulver > CLASSE Computer Group > Cornell University > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Michael DePaulo > Sent: Monday, October 20, 2014 8:16 AM > To: [email protected] > Subject: [X2Go-User] Changing the X2Go Client for Windows version numbering > > X2Go Users, > > I'd like feedback on this topic. > > I am thinking of switching the X2Go Client for Windows version numbering over > to the version numbering that X2Go Client for Mac OS X uses such as: > If X2Go Client for Windows 4.0.3.0 were released today: > 4.0.3.0-20141020 > If I had to make any sort of change, either in the build process or in the > source code, on 2014-11-21: > 4.0.3.0-20141121 > > The reason for this change is that I believe these version numbers will be > simpler and less confusing. This would be especially true for Windows users > who are not used to the version numbering used by Linux distros. > > Under the current version numbering , if I were to build X2Go Client for > Windows 4.0.3.0 when it is released the version number would simply be: > 4.0.3.0 > Then say I had to make 2 changes to the build process, such as calling > different commands during the build process or bundling different 3rd party > binaries/libraries (e.g., VcXsrv, OpenSSL). The 2 new version numbers would > be: > 4.0.3.0+build1 > 4.0.3.0+build2 > If I had to then make a change to the source code, it would be: > 4.0.3.0+hotfix1 > And if I had to make 2 more changes to the build process, the 2 new version > numbers would be: > 4.0.3.0+hotfix1+build1 > 4.0.3.0+hotfix1+build2 > > -Mike#2 > _______________________________________________ > x2go-user mailing list > [email protected] > http://lists.x2go.org/listinfo/x2go-user > _______________________________________________ > x2go-user mailing list > [email protected] > http://lists.x2go.org/listinfo/x2go-user _______________________________________________ x2go-user mailing list [email protected] http://lists.x2go.org/listinfo/x2go-user
