Re: 2008Q1 -> current: downgrade

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Thu, May 22, 2008 at 11:51:12AM +0300, Aleksey Cheusov wrote:
 > [downgrades]
 >
 > pkgsrc versions fetched by 'cvs up -D<DATE>'

The overwhelming majority of what you've found are actually upgrades
documented perfectly well in CHANGES-*. They show up as downgrades to
you and/or pkgsrc-dewey because of disagreements about the semantics
of version numbering, most commonly:

 o  Dated snapshots normally come before numbered releases, but you're
describing the transition as a "downgrade".

 o  Disagreement over whether 1.19 > 1.2 (the "dewey" approach) or 
1.2 > 1.19 (the "decimal number" approach).

 o  Disagreement over whether an alpha/beta version like 1.1b3 comes
before the release version 1.1; it should and I think pkgsrc-dewey
recognizes this if it's presented correctly, but either some old
revisions don't present it correctly or your script did the wrong
thing.

 o  In one case, the use of hex digits in version numbers.

There are also a couple of cases where mistakes transcribing version
numbers into pkgsrc resulted in apparent downgrades, either
immediately or downstream.

There were a couple of cases where upgrades of one of the above forms
failed to make it into CHANGES, which is undesirable but irrelevant to
discussion of downgrades.

There was also one intentional downgrade that was documented in
CHANGES.

Of the eight (yes, only 8) cases remaining from those you posted:

 - Two intentional downgrades that failed to make it into CHANGES:

        20040520 vs. 20050520  converters/xlhtml xlhtml 0.5.1 0.5
        20030520 vs. 20040520  textproc/crimson crimson 1.1.3.1 1.1.3

 - Two PKGREVISION slipups that have since been corrected:

        20060520 vs. 20070520  net/sdig sdig 0.30nb1 0.30
        20050520 vs. 20060520  devel/libslang libslang 1.4.9nb3 1.4.9nb1

 - One case arising from different per-machine versioning of compat_*
packages, probably regrettable but under our own control:

        20070520 vs. 20080520  emulators/compat14 compat14 1.4.3.1nb1 1.4.3nb2

 - One case arising from maintaining an extra local version number
(akin to nb#) without tagging it as such,

        20030520 vs. 20040520  emulators/vmware-module3 vmware-module 3.2.2 
3.2.1.5

 - and all of two cases where the upstream package numbering actually
changed, one because the upstream package was unbundled from
something else, and one for less clear reasons (musical maintainers?):

        20070520 vs. 20080520  devel/python-mode python-mode 4.54nb1 1.0
        20040520 vs. 20050520  www/ap-jk ap-jk 3.2.4 1.2.8


So it doesn't appear that there's much of a market for an epoch
number; there have been all of two or perhaps three proper uses for it
over the past five years.

It is not entirely clear to me what other points you may be trying to
make with this list (or by filing it in a PR). Could you please
explain?

-- 
David A. Holland
dholland%netbsd.org@localhost