← Back to team overview

kicad-developers team mailing list archive

Re: Stable release version numbers.

 

On 10/20/2014 12:38 PM, Nick Østergaard 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 want to keep things as simple as possible.  The numerical triplet
version numbering would only be used for stable releases.  We should
continue to use bzr commit number as the version for daily builds since
they will always be built from the head of the product branch so there
should be no confusion.  I would probably use the triplet instead using
major.minor just in case at some point in the future we decide to
support minor version incremental releases.  Since we have plenty of
time to think about this, there is no need to make a decision right now.
 It's just something to think about.

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




Follow ups

References