On Mon, 14 Apr 2008, David Teigland wrote:
On Sun, Apr 13, 2008 at 01:56:12PM +0200, Fabio M. Di Nitto wrote:
On Fri, 11 Apr 2008, David Teigland wrote:
A new source tarball of cluster code has been released: cluster-2.03.00
This has been taken from the STABLE2 branch in the cluster git tree. It
is compatible with the current stable release of openais (0.80.3), and the
current stable release of the kernel (2.6.24).
ftp://sources.redhat.com/pub/cluster/releases/cluster-2.03.00.tar.gz
Hi David,
I think I either misunderstood the versioning system or I missed something
along the way.
My understanding was that STABLE2 release would have had version 2.02.xx
where xx is incremental per release and a stable SONAME set to 2.2.
Snapshots from master would have taken 2.99.xx and kept an unstable API
set for commodity to 2.9.
I really don't think we should change the SONAME unless there is a need
for it.
I never had a clear plan for when we'd increment the middle number vs when
we'd increment the last number; we've always incremented the middle number
in the handful of past releases.
Ok... i understand where this is coming from.
I've also never understood how .so
naming should be done. Should .so numbers even be associated with the
cluster release numbers?
Partially yes.
I always used this guide to the debian library packaging here:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
It's a bit harsh language towards upstream but it explains all details on
how SONAME's should be handled and it's a short reading for upstreams.
Similar question for .so numbers, what do they mean,
when should they change, when shouldn't they change?
The soname reflects API and ABI of the shared library and they should be
changed according to the guide I mentioned above.
Now we are more or less in this situation:
cluster1/RHEL4 branches are shipping libraries with soname set to 1.0
RHEL5 is shipping soname 2.0
stable2 should have 2.2 (2.3 now is fine since we had one release out with
that number and it's no point to roll back and confuse users) as some
libraries did change.
stable3/RHEL6 will probably have major libraries changes and even if they
might be ABI compatible with the old ones, it's still safe to bump the
soname to 3.0.
The relation ship between soname and version is not always one to one, but
generally the release version gives an indication of the soname and not
the other way around IME.
The two can desync tho. Perhaps at some point we will release a cluster4
with soname 5... who knows.. so far we have been good and lucky enough to
keep those in sync.
As far I am concerned i do not care too much about master respecting the
SONAME rules as long as we make clear to our users that API and ABI can
change (hence using a 2.9 version that indicates an upcoming bump to 3.0).
For stable releases instead we need to be very accurate (or try our best
to be) in handling those bits.
For instance clvm or anything that use a shared library will need a
rebuild if we change soname, and we don't want to force those rebuild
without a reason (see linking section).
What does the release number really "mean"; what
is it useful for?
For us it's an easy way to identify what version a user is running as it
shows virtually everywhere from cman_tool to rgmanager --version or
equivalent.
Since you have a far
better understanding in this area than I do (and you're the one who
actually implements it :-), could you define the rules for us for how this
all works? I don't have any preferences in the matter; I'm open to
whatever you come up with.
So what i think it's good for us is to:
- release stable2 now with version 2.03.xx and increment xx on each
release
- set the soname to 2.3 from now on unless there is a need to bump it.
- we can, at our discrection, change the version to 2.04.xx if there are
general intrusive changes or major stability updates (just an idea).
- release master with version 2.99.xx and increment xx on each release.
- set the soname to 2.9 and ready to bump it to 3.0 when we branch
stable3/rhel6.
the older RHEL5* releases will be released according to whatever you are
used to.
I am open to any other suggestions or ideas tho :)
Fabio
--
I'm going to make him an offer he can't refuse.
