Alistair Crooks wrote:
> On Fri, Jun 10, 2005 at 07:22:14AM +0000, Johnny C. Lam wrote:
> 
>>On Fri, Jun 10, 2005 at 07:54:16AM +0100, Alistair Crooks wrote:
>>
>>This fix falls under the "fix broken compile on platform X" and has
>>historically never led to a version bump.  On systems that already
>>have pkg_install-20050530 installed, there is no difference between
>>it and a pkg_install with Dan's fix.  On OpenBSD and AIX, since it
>>wasn't possible to install pkg_install-20050530 prior to Dan's fix,
>>the only relevant fact is that it's possible to install it now with
>>an updated pkgsrc tree.
> 
> 
> Indeed.
> 
> All of which is a perfectly valid reason to bump the version number.
> 
> It used to be bumped automatically whenever any source file under
> pkg_install was checked in, and I really can't see what the problem is
> to do exactly the same thing here.

The files in pkgtools/pkg_install/files are supposed to mirror the files 
in src/usr.sbin/pkg_install.  According to the CVS log, the version 
number of pkg_install in the "src" module has in the past only bumped 
for changes which are user-visible, e.g., a new flag is added to 
pkg_info(1), fixing a bug in dewey comparisons, etc.

I don't dispute that for released software, one should tag a changed set 
of sources with a different version number, but that hasn't been how the 
version number of pkg_install has been used in the past.  We've used it 
more to version the "API" of pkg_install rather than the source date, 
despite the fact that the version number corresponds to a date.

> What is the limitation or restriction on bumping the version number?

We can choose to change the rules for bumping the version number on 
pkg_install, but it should be clear to everyone that this is a change 
from our existing practice (for pkgtools/pkg_install).  This does make 
it more difficult to keep the pkg_install sources between the "src" and 
"pkgsrc" modules in sync with each other, especially if it's possible 
for the pkgsrc version to have a different version number than the one 
in src.  We could remove this difficulty by having the pkgsrc 
pkg_install be the "master" version of pkg_install and periodically 
pulling those sources into src, instead of the reverse (which is what we 
do right now).  It would then be possible for a pkg_install on NetBSD to 
have a newer version number with no differences whatsoever from an older 
version, but we can certainly live with that.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>