[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] cluster-2.03.00

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).


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:


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
- 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 :)


I'm going to make him an offer he can't refuse.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]