2014-10-20 18:07 GMT+02:00 Benoît Roehr <benoit.roehr...@gmail.com>: > 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:
A lot of info in there, read on. > 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. I am still not really sure what the last should be used to, accoring to Wayne's original suggestion. (maybe I misread something somewhere) > 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) Interresting concept of including the difference in revisions since last release, but I think this is useless, because the project is not big enough IMHO to support this convoluted release process. I would rather replace it with the product branch revision from where the snapshot/release was taken from. This could aslo work even with git where it would be something like 2.1.01315b4, or just 2.1.5231 with bazaar. > 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). I really think that this beta testing you call it, is really not existant as seperate minor-minor releases. The daily builds are responsible for this. > 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". Will also work with my proposed scheme. > That's just an idea.... But I don't know how doable it is...? I think the diff thing is overcomplicating things. I am not really in favour of the time bound version, such as the proposed matlab or altium like versioning scheme. > 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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp