## BEGIN RELEASE VARIABLES ############################ # On making a release... # If this release is just a minor bug fix release, increment GANGLIA_MINOR_VERSION. # If this release adds significant features or breaks backward compatibility, # increment GANGLIA_MINOR_VERSION and set GANGLIA_MICRO_VERSION to 0 (zero). # If this release is a complete restructuring of # the overall architecture of ganglia, # increment GANGLIA_MAJOR_VERSION and set # GANGLIA_MINOR_VERSION and GANGLIA_MICRO_VERSION # to 0 (zero) GANGLIA_RELEASE_NAME="Kittyhawk" GANGLIA_MAJOR_VERSION=2 GANGLIA_MINOR_VERSION=5 GANGLIA_MICRO_VERSION=8# If we are releasing a snapshot (beta), set GANGLIA_SNAPSHOT to "yes" # If we are creating an official release, set it to "no" GANGLIA_SNAPSHOT="yes" # If there are any changes to libganglia in this release, you need to... # LIBGANGLIA_MICRO_VERSION += 1; # LIBGANGLIA_INTERFACE_AGE += 1; # LIBGANGLIA_BINARY_AGE += 1; # if any functions have been added, set LIBGANGLIA_INTERFACE_AGE to 0. # if backwards compatibility has been broken, # set LIBGANGLIA_BINARY_AGE _and_ LIBGANGLIA_INTERFACE_AGE to 0. LIBGANGLIA_MICRO_VERSION=0 LIBGANGLIA_INTERFACE_AGE=0 LIBGANGLIA_BINARY_AGE=0 ### END RELEASE VARIABLES #############################
one of the things this does is to separate out the overall package version from the libganglia interface information. i needed to do this in order to free us from libtool conventions.
i also updated http://ganglia.info/developers/ to add this information. i'll be adding more info there later.
for this particular configuration a ganglia installation would install the following files...
./lib ./lib/libganglia-2.5.8.200411291249.so.0.0.0 ./lib/libganglia-2.5.8.200411291249.so.0 ./lib/libganglia.so ./lib/libganglia.la ./lib/libganglia.a ./include ./include/ganglia.h ./bin ./bin/gstat ./bin/gmetric ./sbin ./sbin/gmond
as you can see, libganglia expresses that it is part of the 2.5.8.... ganglia package with current:release:age set to 0:0:0 (for now). as we add functions to libganglia, this will change (of course). currently, libganglia only exports functions necessary for gexec to automatically collect a load-balanced list of hosts.
we have complete freedom now to set ganglia major, minor and micro versions to whatever we like.
as i wrote in the comments i think we should use the following conventions...
# If this release is just a minor bug fix release, increment GANGLIA_MINOR_VERSION.
# If this release adds significant features or breaks backward compatibility, # increment GANGLIA_MINOR_VERSION and set GANGLIA_MICRO_VERSION to 0 (zero).
# If this release is a complete restructuring of # the overall architecture of ganglia, # increment GANGLIA_MAJOR_VERSION and set # GANGLIA_MINOR_VERSION and GANGLIA_MICRO_VERSION # to 0 (zero)
this is a pretty standard scheme.that means that this release could be 2.5.8 or 2.6.0 depending on how we alter the 2.5.7 code.
since 2.5.0, the addition of metrics hasn't bumped up our minor version. this is because by design gmond ignores multicast messages that it doesn't understand (the metric index is beyond its largest know index). however, i guess adding the unicast support is a pretty significant feature enhancement worthy of a minor version increment.
what do you guys think about this versioning scheme? -matt Federico Sacerdoti wrote:
I like Martin's versioning suggestions. Confusion about compatibility on a project of this size is not good, and instituting a bit of discipline would go a long way.-Federico On Nov 25, 2004, at 8:53 AM, Martin Knoblauch wrote:- changes in "sub" are only bugfixes, tuning and "compatible" changes. As a result, a change in "sub" would not cause trouble on the mcast channel. New binaries would work with the same configuration files as older binaries with same "major.minor". Just drop them in. - changes in "minor" mean incompatibility. Either new metrices, or different behavior, cool new config syntax. A new "minor" release would mean that admins would have to upgrade all gmonds on their grids(s) to keep the mcast channel happy. - changes in "major" would mean real conceptual changes. Like the stuff that Matt has been talking about for a while now. What do you think? Matt? If we follow this scheme, we could declare 2.5.7 the "last" 2.5 cut and call the next release 2.6. I would activate the dummies for 2.6. Or we do 2.5.8 as the final 2.5 release (I would revert the cpu_wio changes to the 2.5.7 state to ensure compatibility) and follow up with 2.6 as above. If we don't implement this change, I would opt for going ahead with 2.5.8 as it is now, activating the dummies in 2.5.9 and live with the confusion.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
