KDE Applications: Custom version numbers in depth

[Alexander Potashev]

Hi,

Recently we discussed if applications that are part of the "KDE
Applications" product should follow the same version numbering system:
yy.mm.patch, e.g. 19.04.2.

After performing a thought experiment, I came to a conclusion that I cannot
property release, say, ktimetracker-5.0.0 with the current KDE Applications
release process (note the version number is different from the standard
19.08.0).

Here is how it goes:

 1. I want a new app release named ktimetracker-5.0.0 which is logical
because the latest release was something like ktimetracker-4.10.13
(kdelibs4-based).

 2. I want the source code for this release to be packed as
ktimetracker-5.0.0.tar.xz, not to confuse those users who want to build the
app from source. (The current release process of KDE Applications fails to
do this already, it assumes all tarballs are named xxx-19.08.0.tar.xz).

Ok, from now on let's imagine the release scripts learn how to name the
tarballs in accordance with the apps' custom version numbers, say
ktimetracker-5.0.0.tar.xz.

 3. Assuming I apply for ktimetracker to join KDE Applications starting
with 19.08 major release, and it passes kdereview, then KDE Applications
19.08 has its release schedule that says a Beta (19.07.80) and Release
Candidate (19.07.90) should be released.

And there is no way release scripts can guess what it would be for
ktimetracker 5.0.0 Beta and ktimetracker 5.0.0 RC and how to name the
tarballs:
 - ktimetracker-4.99.80.tar.xz? (What if we already had
ktimetracker-4.99.80 before?)
 - ktimetracker-5.0.0-beta.tar.xz? (Will every Linux distro understand that
5.0.0 is newer than 5.0.0-beta?)


One radical solution would be to never make Beta/RC releases again.

Any other suggestions?

-- 
Alexander Potashev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20190623/d608b1bb/attachment.html>