On Sat, 14 Jun 2003, Alistair Crooks wrote:

> On Sat, Jun 14, 2003 at 07:58:54AM +1000, Daniel Carosone wrote:
> > 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.
>
> So there are a number of things to take into consideration.
>
> Jim's naming scheme, in conjunction with the way that pkg_info(1) does
> its version numbering, mean that 1.6A is the same as 1.6.1.  This is
> not a good thing.
>
> Whatever does the kernel version have to do with a given userland
> package?

Sorry for being a bit late in this, but at the present time, it's the only
version number we have, and it's used for versioning userland. Even though
it really shouldn't.

> The fact that people have to add the nb version number to another
> file doesn't fill me with awe and wonder. Developers are human, except
> for a few corner cases, and forget to update this file.
>
> Date-based comparison has been used in pkgsrc for the dependency
> checking for around 4 years, and works very well.
>
> Now let's move onto the assertion:
>
> "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."
>
> "provides correct ordering"? No, it doesn't.

For the release branch(es), I think it works well. For -current, I'm not
so sure. We as a project aren't very good about keeping version numbers
up-to-date.

> "control over the granularity"?  So 1.6T is good enough for everyone
> running -current?  When 1.6T has been the kernel version for 2 months?

Probably not.

> Jim hasn't explained why he doesn't like the date number, which is
> logical, simple, and requires no manual futzing.

Perhaps I'm mis-understanding, but I thought his complaint was that the
date was more a compile date rather than the ident-string date used say by
digest or pkg_tools. So just running a "make clean && make" without
changing the source files would give a different date code.

> > The simpler it is for users to determine this, the better.
>
> I completely agree.  "If you're running a package from before
> 20030606, you're vulnerable" seems quite logical and simple to me.
> OTOH, "if you're running a package from 1.6Tnb2 on the -current
> branch, or 1.6.1nb5 on the -release branch" is a bit tenuous to me.

I think we will have to have different values for -release and -current,
since fixes might not make it into the branches as quickly as desired.

Take care,

Bill