Re: handling versioning change

[Marc Espie <espie%nerim.net@localhost>]

In OpenBSD, we introduced EPOCH a few years ago.

Basically, it *has* to be dirty. Hindsight makes perfect
and everything, but EPOCH means "hey we fucked up with the
version number, here's some dirty fix that will work transparently".

Very often, we have to remind newcomers that "epoch is forever"
(NO you can't remove the EPOCH marker from that port).

Notes:
- the way you write it down in the version numbe is not important.
It's a technical detail.  (In OpenBSD, it ends up as a v0, v1... etc
marker at the end of the version part)
- hiding it from the user is a very bad idea.  Version numbering
should be reasonably transparent.  Version ordering obviously has
some security implications, so seeing version numbers go "backward"
for no reason is a very very bad idea.
- deciding that users can and should handle these cases manually
means you don't really want to have a package system.  That's a fairly
common case that can (and should) be automated. IMO.
- putting some kind of "exception" is even worse than EPOCH. Again, this
happens more often than we would like.  But it's nobody's fault. Upstream
changes. porters don't communicate enough with upstream. And we don't
control upstream decision.  But writing special code for each special
upstream case is even worse than having an epoch.

Con:
- *of course* having EPOCH means that fucking up version numbers has
less consequences.  In practice, having peer-review of new ports is
enough for people not to get too sloppy.


So, after those few years, I don't regret for one instant introducing
EPOCH to OpenBSD.  It solved this specific problem completely.