Matthias Andree wrote:
>
> On Thu, 10 Aug 2000, Jamie Lokier wrote:
>
> > Michael Rothwell wrote:
> > > Perhaps the real problem isn't the "feature freeze" but the numbering --
> > > maybe we should still be in the "2.3.xxx" pre-nothing stage currently. Or
> > > the FAQ needs to be updated.
> >
> > Indeed, now that LINUX_VERSION_CODE has the value 0x20400 for all
> > kernels over the last few months, it's impossible to write modules that
> > will compile on all of them :-(
>
> I'm still wondering if it was good to have 2.3.99-pre and
> 2.4.0-test-pre-whatever-other-tag since that gives a nasty and
> difficult-to-handle version numbering. I would have preferred if Linux
> had stuck to 2.3.1xx until the final 2.4.0 series, while it's not my
> decisision, this versioning scheme is a horrible mess.
>
> OTOH, I understand that pre-test series are bugfix series, so APIs
> should not change, however the test-* mapping admittedly flattens that
> VERSION_CODE.
They say hindsight is 20/20. The version numbering should have jumped
patchlevels to denote a milestone, but stayed within 2.3.x. I would
have rather seen this:
2.3.99-pre1 => 2.3.100
2.3.99-pre2 => 2.3.101
... ...
2.3.99-pre9 => 2.3.108
2.4.0-test1 => 2.3.150
... ...
2.4.0-test6 => 2.3.155
The patches could be still have been named as the are now, but every
full kernel release (when a whole tarball is released) whould have a
unique LINUX_VERSION_CODE. All of 2.3.99-preX (9 kernels representing
2.5 months of development) was 0x020363, and all of 2.4.0-testX (6
kernels and another 2 months so far) is 0x020400. We're stuck with
0x020400 until 2.4.1 is released. It's too late to fix it now for
2.3/2.4, but hopefully for the end of 2.5 we can convince Linus to use a
saner version scheme.
--Brian Gerst
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:21 EST