kicad-developers team mailing list archive

[Ian Woloschin <ian@xxxxxxxxxxxxx>]

>From a not-really-developer point of view, I do want to at least recommend
the user of year-based release schemes, similar to how Ubuntu or MATLAB, as
opposed to the more traditional "triplet" style numbering schemes.  From
what I've read here KiCad isn't going to be doing more than a couple of
"stable" releases a year, so why not do something like MATLAB's 2014a/2014b
style releases?

Pros:
Very easy to tell what release you're on, and how old it is
Very clear if a user is using outdated (unsupported?) software
No arbitrary decisions to upgrade a major number (and potentially confuse
users)

Cons:
Very obvious if you don't maintain stable releases over the long term
(...which won't ever happen...right? :/)
Might be tough to line up KiCad releases with major Linux distro releases,
so a user on Ubuntu 16.04 might be stuck on KiCad 2015a (which might not be
a big deal, but it "looks" bad to the uninitiated)
Not always clear if something is drastically new or just a bunch of bug
fixes


For reference regarding MATLAB versions, if anyone isn't familiar with
MATLAB:
http://en.wikipedia.org/wiki/MATLAB#Release_history

On Sun, Oct 19, 2014 at 7:03 PM, Garth Corral <gcorral@xxxxxxxxx> wrote:

>
> 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
>
>
> _______________________________________________
> 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
>
>