kicad-developers team mailing list archive

[Garth Corral <gcorral@xxxxxxxxx>]

Here’s my thoughts from an outsiders perspective.

Using proper version numbers is definitely the right way to go.  Using commit numbers is a horrible way to version a project in my opinion.  Overlapping numbers aside, the commit numbers are arbitrary and have no meaning with respect to the feature set, stability or any other metric that a user might value.  About the best they can do is tell you that source is from an earlier or later commit than another number.  Any meaning that a particular number might have is external to the number and is granted by the development team and is not carried by the number itself, one must map it to some notion that a build is good or bad, usable or not.

I’d go further and say that kicad should discourage the use of stable and development releases.  A version is a version; they are different from commit numbers in that they inherently communicate their suitability for users.  The mere fact that a number was assigned to a set of sources means that someone deemed it suitable for release.  It is for this reason that I would also strongly advise against use of the idiotic scheme of even or odd minor version numbers denoting stable vs. development release.  This has got to be one of the worst bits of release engineering foisted upon open source software.  The idea that one number is a good stable release and the next higher number is somehow bad or unstable is ridiculous. It also breaks the model of numbers that almost everyone on the planet shares.

Development doesn’t need to have releases, per se, nightly builds of the head of a branch of trunk or whatever seems sufficient.  These are presumably for developers consumption and for vetting the latest changes anyway, they don’t need release numbers and could use commit numbers if desired.  At the very least, using commit numbers for development nightlies provides a huge distinction between release and development.   If there must be some number other than the commit number assigned to development builds, then some other scheme such as a 4th tuple that just increments monotonically until the next release is cut, seems to work for other projects.

The traditional triple seems a fine way to go, though I’d argue that what’s in the product series right now is 2.0.0 rather than 1.0.0.  For all intents and purposes, what’s in the current stable series right now is 1.0.0.  It’s out in the wild and has a user base, and there are enough large changes--some of them backwards incompatible--that can justify a larger version.  Even though it was never versioned as such, a 2.0 number implies that there was something before it and this is different enough to warrant your attention.  It might help draw people’s attention to the library changes and whatnot.

Anyway, just my opinion,

Garth


On Oct 19, 2014, at 2:58 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:

> In the past we have used the repo commit number as the stable version
> number.  I'm not sure this is the best idea as there can be overlapping
> commit numbers in separate branches.  I would like to propose using
> something that we can clearly identify as a release version to prevent
> confusion due to duplicate commit version numbers.  I recently committed
> the stable release policy to the developers documentation but I
> intentionally left out the version number section because I wanted to
> make sure we are on board with the idea.  It would make it clear to
> developers, users and packagers that they are using a stable release
> versus a development release.  It also makes it easier to name source
> and binary packages.  I'm perfectly happy using the good old fashioned
> numerical triplet (#.#.#).  It's easy for most version comparison
> functions to deal with.  I suggest for the next stable release we start
> at the beginning 1.0.0.  If no one objects, I will update the stable
> release policy and add the code to CMakeLists.txt before we get to the
> next stable release.
> 
> Thanks,
> 
> Wayne
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature