cvs commit: src/usr.sbin/config configvers.h mkmakefile.c src/sys/conf Makefile.alpha Makefile.amd64 Makefile.arm Makefile.i386 Makefile.ia64 Makefile.pc98 Makefile.powerpc Makefile.sparc64 files files.alpha files.amd64 files.i386 ...

[Warner Losh]

> On Mon, Nov 28, 2005 at 11:59:18AM -0500, John Baldwin wrote:
> > On Monday 28 November 2005 11:24 am, Ruslan Ermilov wrote:
> > > On Mon, Nov 28, 2005 at 08:53:32AM -0500, John Baldwin wrote:
> > > > On Sunday 27 November 2005 06:38 pm, M. Warner Losh wrote:
> > > > > How does this look to you?
> > > >
> > > > What is the point of the minor version number then if it is never
> > > > checked?  I think we just should not do bumps for changes to config that
> > > > allow old files to still work.  IOW, the most recent bump should simply
> > > > be reverted.  In practice I don't think many folks other than developers
> > > > ever end up with a config that is out of date with the kernel sources.
> > >
> > > The old config(8) against new files should also be considered.
> > > Otherwise, in this case, if it's reverted, how can I express
> > > that new sys/conf/files* require a new config(8)?  The old
> > > config(8) will _appear_ to work with them, but will produce
> > > incorrect output (exactly the problem config version attempts
> > > to address).  Specifically, "|" will be treated as a device.
> > 
> > Hmm, that change might actually warrant a bump then.  Things like the 
> > 'machine' change would not warrant a bump however.
> > 
> Indeed, I didn't bump it for the "machine" change.  The idea
> Warner attempts to implement is to bump a major whenever a
> backwards incompatible change is made, and bump a minor when
> a change is made such that a backward compatibility is not
> affected.  This would allow for config versions >= the
> required version to work.  I'd then bump the config version
> along with the change, and bump the required version in
> makefiles when doing a change to conf/files* (in this
> particular case).

We have backward compatibility, but no forward.  We can use
7-current's config to configure 6.x's kernels, but that the 6.x config
would complain that a newer config was needed when it is run on
7-current's kernels.

We could have (and should have) done this for 6.0, but didn't
understand the problem in time.  Had we done that, then we could
configure all the way back to sometime in the 5.x series of releases
from head.  I suppose I could special case this, but to be honest, I'm
not sure that uglifying the code in this way would be worth it given
how quickly 6.0 and RELENG_6 seems to be being adopted.

Warner