kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2014-10-20 19:00 GMT+02:00 Garth Corral <gcorral@xxxxxxxxx>:
> 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 <oe.nick@xxxxxxxxx> wrote:
>
>> 2014-10-20 18:07 GMT+02:00 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:
>>
>> 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@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
>>
>> _______________________________________________
>> 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
>