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
