Version stuff in CMakeLists.txt
Jaroslaw Staniek
staniek at kde.org
Thu Jan 5 10:29:20 GMT 2017
On 5 January 2017 at 11:12, Dag <danders at get2net.dk> wrote:
> Jaroslaw Staniek skrev den 2017-01-05 10:50:
>
>> On 5 January 2017 at 08:59, Dag <danders at get2net.dk> wrote:
>>
>> Had a closer look at this, and there is some cmake logic when
>>> generating calligraversion.h:
>>> Any 3.0.x unstable (alpha/beta/rc) will get version 2.99.x. (3.1.x
>>> will be 3.0.x, etc)
>>> Afaics this scheme only works when a minor version is increased, e.g
>>> 3.0.x -> 3.1.0.
>>> Is this a disaster? Probably not. If you add a conditional compile
>>> e.g in 3.0.1 you cannot test in an unstable release, but that would
>>> not be often, I think.
>>>
>>> Alternatives:
>>> 1) Add a unstable release number as proposed by Rene.
>>>
>>> 2) Drop the special unstable numbers (89, 90..) and use the release
>>> number as a sequential number.
>>> E.g: We released stable 3.0.0, so now the unstable will get 3.0.1
>>> (string could be 3.0.1 Alpha) and when we make a new release it
>>> would be 3.0.2.
>>> This will give unique and increasing version numbers, with the
>>> drawback that you can not see from version alone if it is unstable
>>> or stable, but we can use version string for that.
>>>
>>> Opinions?
>>>
>>
>> IIRC we release no alphas. Even when we had that, we release no alphas
>> the patch version - for x.y.z (z>0).
>> x.(y-1).89 is thus compatible with the sequence, it comes after all
>> x.(y-1).* stable and before the next stable x.y.z.
>>
> Hmmm, do you mean we only release unstable when minor version is updated,
> in which case this will (almost) work?
>
After 2.9.11 our 3.0.0 beta was 2.9.8x or so (regardless of the fact if it
was physically released). All version are in sequence as in semantic
versioning.
As you see minor version was not updated, it was still 9. It turned 0
since 3.0.0.
https://community.kde.org/Calligra/Schedules/2.9/Release_Plan
> I think we still have the problem that the version in git will get a lower
> version than the last version released, but as said above we could live
> with that.
>
>
>> Between 3.0.0 and 3.0.1 there's no extra number needed.
>>
>> What we had with the x.y.z.v was special I think. (?)
>>
> Yes, forget that.
>
>>
>>
>>
>> Dag skrev den 2017-01-04 10:45:
>>>
>>> I can't figure out how this is meant to be used.
>>>>
>>>> We have now released 3.0.0.1. Next should probably be 3.0.1.
>>>> So I gather current should be an alpha:
>>>> Major: 3
>>>> Minor: 0
>>>> Release: 89
>>>>
>>>> But then we would go backwards to Release: 1 when releasing,
>>>> and after that we go to Release: 89 again and we can't see
>>>> what 3.0.89 actually means as it will crop up for every new 3.0
>>>> release.
>>>>
>>>> Is it just me being confused, or...
>>>> Anybody?
>>>>
>>>
>> --
>> regards, Jaroslaw Staniek
>>
>> KDE:
>> : A world-wide network of software engineers, artists, writers,
>> translators
>> : and facilitators committed to Free Software development -
>> http://kde.org
>> Calligra Suite:
>> : A graphic art and office suite - http://calligra.org
>> Kexi:
>> : A visual database apps builder - http://calligra.org/kexi
>> Qt Certified Specialist:
>> : http://www.linkedin.com/in/jstaniek [1]
>>
>> Links:
>> ------
>> [1] http://www.linkedin.com/in/jstaniek
>>
>
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20170105/d9bfc798/attachment.htm>
More information about the calligra-devel
mailing list