2014-10-20 19:00 GMT+02:00 Garth Corral <[email protected]>: > I agree with all points here, with one exception and one caveat. > > The exception is that it will not work well with git (not an issue here). > Git commit IDs are not ordered and trying to use them as versions is a world > of pain. You’ll just have to trust me on that. > > The caveat is that if you’re going to use that third place for the commit > numbers you have to be certain that you’re never going to need it for a patch > release. E.g., 2.1 slips out with that nasty crasher and you need 2.2.1 to > fix it. Otherwise you add a small bit of confusion. Which is why I > suggested the 4th number in my original email, which could accommodate the > commit number as suggested here.
Well I would not describe this as a caveant or problem. In my suggestion it is only 2.1 (or 2.1.0 if we choose a triplet for relase versions) that is the version, while the vcs version is just for convience. And should probably not be seen in the package manager. I know that a tag upstream should serve this purpose. But let this git discussion end with this period. > > Garth > > > On Oct 20, 2014, at 9:38 AM, Nick Østergaard <[email protected]> wrote: > >> 2014-10-20 18:07 GMT+02:00 Benoît Roehr <[email protected]>: >>> 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 : [email protected] >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
