> So far noone suggested ANYTHING better then implement-try-and-reimplement
> style of development. Of course you can (and SHOULD) try to avoid as much
> uglyness as possible but in the end story is always the same: something was
> not taked into account when API/driver interaface/cacheing sysbsystem/whatever
> was developed. Better to have well-established way to eliminate obsoleted/ugly
> things in planned fashion then try to keep all accumulated cruft... You MUST
> expect breakage when upgrading from 1.2 to 2.0, from 2.0 to 2.2, from
> 2.2 to 2.4 and so on...
Maybe we could switch to the standard library versioning system, i.e.:
major.minor.patchlevel
Where patchlevel changes indicate bugfixes only, minor version changes
indicate new features but no change to existing APIs, and major version
changes happen when you deliberately break existing APIs for cruft
clearing.
Drivers (and driver writers) would then know that code written for Linux
e.g. 9.7.43 would work for any future Linux 9.foo.bar kernel, but not for
Linux 10.wibble.fish. It might have a minimum required minor version if it
relies on a new API introduced.
At the moment it seems there's no technical reason whether a new release
gets a minor version or a full major version bump; it's more a PR thing --
2.0 was a lot different from 1.2, but then 2.4 will be a lot different from
2.2 (esp. for SMP people), but I doubt it will become Linux 3.0, somehow.
--
"But we're a university. We /have/ to have a library!..."said Ridcully,
"What sort of people would we be if we didn't go into the library?"
"Students", said the Senior Wrangler, morosely. [TP: The Last Continent]
-
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/