On Thu, Feb 03, 2005 at 12:27:57AM -0800, Martin Knoblauch wrote: > > --- Brooks Davis <[EMAIL PROTECTED]> wrote: > > > On Tue, Feb 01, 2005 at 09:43:29PM -0800, Matt Massie wrote: > > > guys- > > > > > > i'd like to have an informal vote. please email whether you think > > this > > > release should be 2.6.0 or 3.0.0. > > > > You already know my position, but let me expand of my reasoning. In > > my > > opinion, version numbers are sign posts for users. When a user sees > > the > > minor version change, they don't (or at least shouldn't) expect to > > have > > to replace all their config files. They should expect to have to > > read > > the release notes and the might want to make some change, but as I > > user > > I don't expect be forced to make changes on every machine a piece of > > software is installed on. If I see a major version change, I know I > > will > > probably need to make changed in my deployment or even redeploy > > entirely. That's the case with this release. > > > > If you accept that version numbers are for users, also accept that > > users > > don't care about your implementation. It's almost entirely > > irrelevant > > (there are some exceptions of course, but they are nearly all > > emotional > > issues such as convincing people that programs written in Java aren't > > slow). All users care about is how they use the program and what it > > does. > > > > There are exceptions to this scheme. OpenSSL for instance makes > > incompatible changes to well established config file formats, APIs, > > and > > ABIs and then changes the tertiary number. This leads to the fact > > that > > every security officer and OS release engineer I know curses them on > > a > > regular basis. > > > > -- Brooks > > > Hi Brooks, > > your reasoning from a users point of view makes a lot of sense to me. > But frankly, we should then drop the "micro" number from the scheme and > increment "major" much more frequently. In the past "major" was more or > less a constant value, while "minor" kind of defined the compatibility > level and "micro" was for the patches. > > So, lets make it: > > - major: increments imply incompatible changes > - minor: increments imply only compatible changes/features and bug > fixes > - micro: drop > > or (to keep a three level scheme) > > - major: increments imply incompatible changes > - minor: increments imply only compatible changes or compatible new > features > - micro: bug fixes only > > Just make sure that Matt does a proper CVS branch when he starts > working on the cool new post 3.x stuff. Because we likely have to run a > maintenance stream for quite a while.
I generally agree. In FreeBSD we don't use a minor except for "crap! we just shipped a release with a remote vulnerability in the default install" and then only if the CD vendors haven't pressed CDs yet. Ganglia is different in that excluding support code it's under 250 thousand lines of code where at the FreeBSD kernel alone is well over 5 million lines thus ganglia can have a much more compressed development cycle which can lead to different decisions of versioning. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgpeBCL77Y90a.pgp
Description: PGP signature
