kicad-developers team mailing list archive

[Benoît Roehr <benoit.roehr.ec@xxxxxxxxx>]

Not a dev, but my 2 femto cents:

I really like the #major.#minor.#dev - #buildNo scheme, but I would add 
these details about the version incrementation:

2.0
New release, majors changes over the 1.9.

2.1.0
Stable release with new features and bug fixes over 2.0.0.

2.1.25
Development version, unstable/beta releases for edgers and tests. #dev 
is calulated with build number. If v2.1.0 was build 6120, v2.1.25 may be 
build 6145. (6145 - 6120 = 25)

If 2.1.25 is tested and stable, then it is renamed 2.2.0 and released. 
Reference buildNo is now 6145 (avoid code regression).

Edgers using beta before release would see v2.1 in windows description, 
and 2.1.25 - 6145 in "about".
After release, users would see v2.2, and v2.2.0 - 6145 in "about".

That's just an idea.... But I don't know how doable it is...?


On 20/10/2014 17:27, Tomasz Wlostowski wrote:
> On 20.10.2014 17:25, Marco Ciampa wrote:
> > On Mon, Oct 20, 2014 at 08:47:54AM -0400, Carl Poirier wrote:
> > > I feel like we wouldn't use the last digit much in a triplet number
> > > because, IIRC, backporting of fixes is not planned. That being said, I
> > > would also begin with at least 2.1, as Cirilo said.
> > >
> > > However, I personally vote for numbering the versions a la MATLAB.
> >
> > I am not a dev, I know, so my 0.002 cents on N.N numbering starting 
> > from 2.0
> > or 2.1 ...
> How about an Ubuntu-ish scheme with year/month? e.g. 2015.01?
>
> My 10e-6 cents...
>
> Cheers,
> Tom
>
>
> _______________________________________________
> 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