Re: KDE Applications: Custom version numbers in depth
On 6/25/19 11:55 PM, Albert Astals Cid wrote: Any other suggestions? You stop caring about the 2 people that will get confused about the version number in the tarball name :) An alternative idea: you can adopt the bundle's own versioning scheme at the time when the app joins the bundle, which will solve all the mentioned problems and also make your life easier because all the version number bumps will be taken care of for you automatically. ;) Nate
Re: KDE Applications: Custom version numbers in depth
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
Re: KDE Applications: Custom version numbers in depth
On Sun, Jun 23, 2019 at 01:16:33AM +0300, Alexander Potashev wrote: > 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). I think my radical suggestion would be to accept changing the version naming convention for ktimetracker to match KDE Applications. i.e. you'd go straight from 4.10.13 to 19.08 for the first KF5-based release under KDE Applications. I had to do a similar thing for juk and it didn't lead to any notable confusion, and in fact reduced confusion for users who weren't sure what "version" to enter against JuK bugs in bugzilla. It's also easier for me to maintain since Bugzilla versions are created automatically now, the release scripts can take care of tagging in git for me, and so on. You could announce this change as part of the migration to 19.08, which means your beta and RC releases could be done and would be under the KDE Applications scheme. Regards, - Michael Pyne
