kicad-developers team mailing list archive

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

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