On 11/18/2015 04:15 PM, Stanislav Ochotnicky wrote:
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.
And? These things also rely on rpm to sort 1 before 2. Not to mention a
whole pile of other, far more obscure rules than those.
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.
Beta/rc are part of the version just as much as micro-versions are. That
they are traditionally mapped to the tail end of the release in rpm
world is just another historical rpm abomination.
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
Right. Only took eight years for anybody to notice ;)
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
