Re: [Ganglia-developers] version number

[Matt Massie]

we'll just call them 4.0 or wherever we happen to be at the time. they aren't dead. i just put them on hold to work on 3.0.x.

-matt

Federico Sacerdoti wrote:

Matt,


-Federico

On Feb 2, 2005, at 4:20 AM, Matt Massie wrote:

Didn't your 3.0 design have many other things in it, like DSO support, a variable metric space, a full query interface, etc? And many other things that I dont quite remember now. Are those designs dead, or will you call them Ganglia 4.0.

great.  so we have 2 votes for 3.0.0 and 2 votes for 2.6.0.  :)



one of the reasons i thought we should call it 2.6.x is that you can mix










-matt


Brooks Davis wrote:

i don't mean to be a "flip-flopper" but now i'm leaning toward calling this 3.0.0. i just opened up the debate to people here and in the end it seems like 3.0.0 makes a little more sense. 2.5.x and the new gmond on the same network channel and they will be okay (except for solaris machines since we had to fix that communcation bug). we are really not incompatible on the network rather only in the way gmond configures itself at startup. but to use the apache web server as an analogy. HTTP 1.0 and HTTP 1.1 are standards... apache 1.3 and 2.0 implement those network standards but in very different ways (then again web servers talk to clients only and not each other). i think brooks has a point that i need to think in terms of user expectation more. it is a significant change to require a new config file format, and to add all the features in the announcement we've been bouncing around. moving from a threads model to an async io. ipv6 support etc. i was thinking that i could add support for both file format in gmond but i think that would a support nightmare. so now i'm 60% in favor of calling it 3.0.0 and 40% in favor of 2.6.0. unless i hear more good ideas in favor of 2.6.0.

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

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

software is installed on. If I see a major version change, I know I will

--
PGP fingerprint 'A7C2 3C2F 8445 AD3C 135E F40B 242A 5984 ACBC 91D3'

   They that can give up essential liberty to obtain a little
      temporary safety deserve neither liberty nor safety.
  --Benjamin Franklin, Historical Review of Pennsylvania, 1759

Federico

Rocks Cluster Group, San Diego Supercomputer Center, CA

--
PGP fingerprint 'A7C2 3C2F 8445 AD3C 135E F40B 242A 5984 ACBC 91D3'

   They that can give up essential liberty to obtain a little
      temporary safety deserve neither liberty nor safety.
  --Benjamin Franklin, Historical Review of Pennsylvania, 1759

signature.asc
Description: OpenPGP digital signature