[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-release-team
Subject: KDE Applications: Custom version numbers in depth
From: Alexander Potashev <aspotashev () gmail ! com>
Date: 2019-06-22 22:16:33
Message-ID: CADMG6+-yhSEco5mjhc6+EW4iyP=6MQMG5u4ZmjcqKtiw_HSd=g () mail ! gmail ! com
[Download RAW message or body]
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
[Attachment #3 (text/html)]
<div dir="auto">Hi,<div dir="auto"><br></div><div dir="auto">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.</div><div \
dir="auto"><br></div><div dir="auto">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 <span style="font-family:sans-serif">(note the \
version number is different from the standard 19.08.0).</span></div><div \
dir="auto"><span style="font-family:sans-serif"><br></span></div><div \
dir="auto"><span style="font-family:sans-serif">Here is how it goes:</span></div><div \
dir="auto"><span style="font-family:sans-serif"><br></span></div><div \
dir="auto"><span style="font-family:sans-serif"> 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).</span></div><div dir="auto"><span \
style="font-family:sans-serif"><br></span></div><div dir="auto"><span \
style="font-family:sans-serif"> 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).</span></div><div \
dir="auto"><span style="font-family:sans-serif"><br></span></div><div \
dir="auto"><span style="font-family:sans-serif">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.</span></div><div \
dir="auto"><span style="font-family:sans-serif"><br></span></div><div \
dir="auto"><span style="font-family:sans-serif"> 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.</span></div><div \
dir="auto"><span style="font-family:sans-serif"><br></span></div><div \
dir="auto"><span style="font-family:sans-serif">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:</span></div><div dir="auto"><span \
style="font-family:sans-serif"> - ktimetracker-4.99.80.tar.xz? (What if we already \
had ktimetracker-4.99.80 before?)</span></div><div dir="auto"><span \
style="font-family:sans-serif"> - ktimetracker-5.0.0-beta.tar.xz? (Will every Linux \
distro understand that 5.0.0 is newer than 5.0.0-beta?)</span></div><div \
dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">One radical solution \
would be to never make Beta/RC releases again.</div><div dir="auto"><br></div><div \
dir="auto">Any other suggestions?</div><div dir="auto"><br></div><div dir="auto">-- \
</div><div dir="auto">Alexander Potashev</div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic