On Fri, 11 Feb 2000, David Brownlee wrote:

> On Thu, 10 Feb 2000, David Maxwell wrote:
> 
> > No major/minor numbers were changed from 1.4 -> 1.4.x 
> > Is that a rule?  I suspect I wouldn't have noticed it if it were stated, but
> > I don't recall it.
> > 
> 	Its implicit in the 'no changes that break existing functionality'
> 	goal.

Actually it's not. The only requirement 'no changes that break existing
functionality' places is that a shared library not disapear. Like say we
bump the major number on a shared lib (libutil comes to mind) between
point releases (say between 1.4.2 and 1.4.3 - values chosen to not scare
anyone right now). In the new point release (1.4.3 here), there would need
to still be a shared lib with the old major number.

Bumping minor numbers would be fine, and would cover upgrades in
functionality.

The reason to not change version numbers in a point release is subtly
different. It's to keep our heads from exploding. :-) It's because shared
libraries are versioned in a strictly numerical name space. I believe 1.4
shipped with libc 12.40. -current is now at 12.55. At some point -current
was at 12.41. If we bumped the -release branch shared lib number to 12.41,
unless we added all of the new routines -current ganed in 12.41 and no
more, we'd have an ambiguity. The -current -12.41 would be different from
the -release 12.41. And thus our heads might pop. :-)

> > So, that said, I can't think of any other issues with replacing a
> > 1.4 package with a 1.4.1 (etc) package.
> 
> 	OK - I've been convinced. I'm now on the 'merge point releases
> 	into one dir' side of the fence.

I'd vote not. I'm not sure if it was reverted, but 1.4.1+ had an
lkm-breaking change. So filesystem packages would be different before and
after that change.

The change I am thinking of was to bump some counters in struct vnode. I
think we also bumped reference counters in struct route (and if we didn't,
we should). So point releases might have kernel interface changes, which
would necessitate different packages.

Take care,

Bill