On Thu, Jun 12, 2003 at 10:24:38PM -0400, Jim Wise wrote:
> As far as I can tell, with regpkg as currently committed, if I compile
> _identical_ code on two different dates, I get different version
> numbers.  Plus which, is a pkg versioned 20030614 built from the branch
> `newer' or older than one with the same version number built from
> - -current?
> 
> More damningly, if i compile newer code and then compile older code, the
> older code gets a newer version number.  This, obviously, makes it
> infeasible to include `affected' syspkg versions in SAs.
> 
> In contrast, the system which was discussed on the mailing lists,
> documented, implemented, and committed previously, provides a constant
> version number for constant code, provides correct ordering for newer
> and older code, and gives us control over the granularity we want for
> syspkg version numbers.

I don't want to wade into the argument over commit-now-or-later.
I don't want to wade into the argument over version number format.
I don't want to wade into the argument over implementation details.
I don't know where this discussion has gone since it moved to
tech-install, since I don't read that list.

I hope you guys can talk this out amicably and come to a reasonable
conclusion.

That being said, I strongly hope that the conclusion has versioning
behaviour similar to what Jim describes above.  It really is
important.  My interest is obviously the SA case, and this is a
clear example of a need for the above behaviour, but there
are others.

I think there's probably good reason for the version numbers to
bump "automatically" too, such as when dependencies bump, and other
events.  We don't want to force all version bumps to require manual
developer effort - or some will be missed.

In other words, for the SA case, I don't care how many other version
bumps happen between one SA for the ssh package and the next.  I
just need to be able to say in an SA: "if you have a version <X,
you are vulnerable to this issue, please upgrade to at least version
X".

The simpler it is for users to determine this, the better.

--
Dan.