From: Achim Gratz <Stromeko@Nexgo.DE>
To: cygwin-apps@cygwin.com
Subject: Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
Date: Tue, 31 Oct 2017 10:06:00 -0000 [thread overview]
Message-ID: <ot9hub$3if$1@blaine.gmane.org> (raw)
In-Reply-To: <4eb3bda2-c6a2-bc48-d042-d54229a28514@dronecode.org.uk>
Am 30.10.2017 um 16:58 schrieb Jon Turney:
> "everyone" != "everyone, ignoring people who disagree with me"
I think this is an unfair summary of my position.
> If you think epochs are a bad idea, you need to give reasons, not just
> pretend there is no debate.
I was strictly talking about those folks who've had the opportunity in
practise so far, which is all the major GNU/Linux distributions. The
ones I'm aware of aren't using epochs and instead decided to use other
means of achieving the same (or similar) goals. In fact they created
rules to not use epochs even though the tools support them. Their line
of reasoning always was (and still is), that once you start using epochs
there is no way going back and you could just as well have used
monotonic release numbers instead of versions. The other point is that
it is close to impossible that everybody will agree on what the epoch
ought to be. The last point is that once an epoch bump is introduced,
you can't decide to sort things differently unless you're prepared to
invalidate all existing released packages.
So, we might have that debate now for Cygwin because we might finally
use a library that supports epochs, but others have been there before us
and concluded that epochs aren't worth the trouble. I don't see our
situation with Cygwin different enough to come to a different conclusion
than the distro folks and they've had many more brains to pick on this
issue.
> I agree it does not work well for CPAN-style floating point version
> numbers, but that's your problem to solve, or not, however you like...
You can stop using this particular example if it helps you not taking a
right at Albuquerque each time version numbers come up. This is just
one of many examples where two sets of sane versioning rules don't
produce the same ordering.
There are plenty of other examples where versioning upstream for
whatever reason doesn't conform to whatever set of rules to make them
sortable and it's not all that unheard of that upstream decides to
change their rules once in a while even if they otherwise keep their stride.
So whatever the reason, you will have to impose a sort order whenever
there is a package that doesn't follow the rules builtin to setup and
hence sorts incorrectly. You say epochs are _the_ way to do that and
I'm pointing out that the distro folks have come to the conclusion that
it isn't and are using different mechanisms.
--
Achim.
(on the road :-)
next prev parent reply other threads:[~2017-10-31 10:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-27 18:47 Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 1/3] Remove the function filemanip.cc:base Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 2/3] Bump the installed.db version to 4 Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 3/3] Remove the ScanFindVisitor class Ken Brown
2017-10-27 19:27 ` [[PATCH setup] 0/3] Prepare for colons in version numbers Achim Gratz
2017-10-27 19:33 ` Ken Brown
2017-10-27 19:48 ` Brian Inglis
2017-10-27 20:31 ` Yaakov Selkowitz
2017-10-30 15:58 ` Jon Turney
2017-10-31 10:06 ` Achim Gratz [this message]
2017-10-31 11:21 ` Corinna Vinschen
2017-10-31 16:22 ` Brian Inglis
2017-10-31 18:16 ` Achim Gratz
2017-10-31 18:32 ` Brian Inglis
2017-10-30 15:55 ` Jon Turney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ot9hub$3if$1@blaine.gmane.org' \
--to=stromeko@nexgo.de \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).