On Sat 07 Nov 2015 10:18:14 AM EST Panu Matilainen <pmatilai@xxxxxxxxxxxxxxx> wrote: > Frankly I didn't even realize the 0.rc1.X scheme was against the > guidelines since to me this is the (obviously) correct way to do it with > predictable pre-release names (its predictable when you're the one doing > the upstream tarballs), where the versioning goes like this: > > 0.beta1.1 > 0.beta1.2 > 0.beta1.3 > 0.beta2.1 > 0.beta2.2 > 0.rc1.1 > 0.rc1.2 > [...] > 0.rc1.5 > 0.rc2.1 > 1 (for the final) Above relies on rpm to sort b before r. It also assumes as others have mentioned that you don't have an emergency situation where you need to do one-off in the middle. > The scheme in guidelines of course works no matter what wacko > names-of-pet-ponies versions upstream tarballs may have, but to me its > "wrong" in the sense the release number doesn't get reset between > version changes. By "version" you are talking the upstream beta/rc etc labels right? Because you certainly can and should reset the release number on version changes. > Not that I'm defending going against the guidelines or > arguing for changing it (I'm way too old to get involved in THAT again), > just explaining where this particular offense in case of rpm probably > originates from. Feel free to consider it as an apology for setting a > bad example. Meh, you are not the first nor the last. It's just that we (rightfully?) hold package managers to higher standards -- Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx> Business System Analyst, PnT DevOps PMO Team - Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
