Subject: syspkg versioning (Re: CVS commit: src/distrib/sets)
To: Jim Wise <>
From: Chris Gilbert <>
List: tech-install
Date: 06/13/2003 09:37:27
(note switching to tech-install)

On Thu, 12 Jun 2003 22:24:38 -0400 (EDT)
Jim Wise <> wrote:

> Hash: SHA1
> On Fri, 13 Jun 2003, Alistair Crooks wrote:
> >On Thu, Jun 12, 2003 at 08:34:49PM -0400, Jim Wise wrote:
> >> Is there a reason the ability to explicitly version system packages
> >was> discarded?  Previously, a system package on a release branch was
> >> versioned with the current OS version of the branch, plus a `tiny'
> >> version number of the syspkg, such as
> >>
> >> 	base-util-bin-
> >>
> >> for the version of that package that shipped with 1.6.0, and
> >>
> >> 	base-util-bin-
> >>
> >> for a hypothetical first `relevant' update to that package (such as
> >when> an SA was issued for a binary in the package).  This allows
> >tracking of> `important' changes in such a syspkg, much like the
> >`nbXX' version> add-ons in pkgsrc.
> >
> >The old versions don't work at all well on -current, and anything
> >which discourages people from running the -current branch should be
> >discouraged, IMO.
> >
> >The old versions numbers were coming out as 1.6T-0. This is too
> >large a granularity, and are not at all friendly.
> I guess I don't buy this -- the version numbers are consistent, add a
> single piece of information to the version number we _already_ use for
> the release, and increase monotonically.

This has been discussed before, one of the suggestions at the time (so
that the numbering makes sense?) was something akin to:

1.6.0.x    1.6.0 release branch with updates  1.6.1 pre-release, RC's, betas etc
1.6.1.x    1.6.1 release branch

1.6.98.x   -current post 1.6 branching, where x is filled by the letter,
eg 1.6T becomes
1.6.99.x   2.0.0 pre-release code, alpha, betas, rc's etc, bump the last
for each one (or even structure it, eg 0-9 are alphas, 10-19 are betas,
20-30 are rc's)
2.0.0.x    2.0.0 release
2.0.98.x   -current post 2.0 branching

A few points with the above:
easy upgrades to something newer, eg easy go from 1.6 -current to 2.0
the rc's etc are numerically a lower version than the release.
Note the above doesn't cover prerelease versions of 1.6.1

Note I know it's probably not perfect, but it's potentially a workable

Note that one thing that syspkgs may introduce, is the need to branch
1.6.0 from the 1.6 release branch, so that the 1.6.0 branch is completly
clean to have SA's etc applied to it.  Eg would be tricky to release a
1.6.0 SA package if 1.6.1 was in pre-release rc's, and it wasn't
branched.  Note the exact point of branch may not be that quickly after
release, depends on what happens on that branch.

Whatever numbering scheme we do use it has to sensibly cope with these

With the above we would end up with something akin to:

-current		1.6 release branch		maintenance branches
   |                          |         
   |                          |
   |                                   |
   |                                   |
   |                          *-------------------------------\                      |                               |
   |                                    2.0.0.x 
   |                          |                            
   |                          |
   |                          *-------------------------------\
   |                          |                               |
   |                                    2.0.1.x