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