El diumenge, 23 de juny de 2019, a les 0:16:33 CEST, Alexander Potashev va escriure: > 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.
That's not a possibility :) > > Any other suggestions? You stop caring about the 2 people that will get confused about the version number in the tarball name :) Cheers, Albert
