Hi,
Launching a discussion about versionning is a really good idea...
actually we started some times ago, while releasing the version 0.5 of
Carob, and here is what got out:
1. yes, we do need to keep track of compatibilities between carob&friend
vs. sequoia.
2. but it will be confusing/'heavy' to carry this tracking in the
version numbering:
eg. if you take a notation like carob-1.0-sequoia-2.7, this quite a long
naming ! moreover, it is a bit confusing: next version will be
carob-1.0-sequoia-2.8, or carob-2.0-sequoia-2.7. It does *not* look like
any known version numbering convention and I think that users will be
lost with this
3. what appeared to us as a quite good solution is to maintain a
"version compatibility table" on carob's web page. We only keep carob's
numbering carob-x.y (x = major, y=minor), just like you suggested and
then, on the web page, we may have the following:
carob version | compatible sequoia version
-----------------------------------------------
carob-1.0 | sequoia-2.7
----------------+------------------------------
carob-1.1 | sequoia-2.8
----------------|
carob-1.2 |
================|
carob-2.0 |
----------------+------------------------------
carob-2.1 | sequoia-2.9
And same for libmysequoia/odbsequoia...
What do you think about that ?
4. About the version fall-back inside sequoia, I think yes, it would be
nice but.... :) it would make the code more and more heavy (and sequoia
really doesn't need that !), it is quite a big thing to do, especially
in these times of hurry. Sure, it is a good thing, but I think we should
not count on this before years...
Let's keep the discussion on going...
Gilles.
Csaba Simon a écrit :
Hi all,
This email is a call for discussion for Carob library versioning.
Currently Carob does not have one.
Some notions before we start.
A library has a MAJOR and a MINOR version number reflecting the
*interface* number.
* Major: every time the interface is changed (removing functions,
changing function calls, modifying structures) this number is
incremented by 1 and the minor number is resetted to 0.
* Minor: is incremented by 1 for adding new functions, bugfixes.
Applications linked to previous version will still work with this
version. Application linked to this version will not work with
previous version.
Binary and source compatibility:
* Binary: means that a compiled application can be linked dynamically
against the library and continue to function properly.
* Source: means that an application compiled against a particular
version will continue to be linkable against later versions.
We have binary compatibility when the major number is the same.
Example: 2.0, 2.1, 2.4 are ABI compatible. They have different minor
versions but the major version is the same.
The program version and the library version can be different. Example
for libpng:
program version interface version
libpng 1.0.x 1
libpng 1.2.5 2
libpng 1.2.6 3
But also can be the same. Example for gtk+:
program version interface version
gtk+ 1.2.0 1.2
gtk+ 2.0.0 2.0
gtk+ 2.2.1 2.2
Enough from the theory let's get back to why I started this mail.
We need to choose a library version strategy for Carob. First I was
tempted to have the same version numbers as Sequoia. For example Carob
2.7 for Sequoia 2.7, Carob 2.8 for Sequoia 2.8. This means that Carob
2.7 and Carob 2.8 are ABI compatible? Or between Carob 2.8 and Carob
3.0 their is a big ABI incompatible change? The answer is *no* so I
dropped the idea.
Now the brainstorming can start. The question is how can we make a
simple version schema:
* where we can follow the ABI compatibility
* where we can know exactly the version number(s) for Sequoia what
will work with our library (for example: this version of Carob will
work with Sequoia 2.6 and 2.7 but not with Sequoia 2.8)
We need to track the *interface* version (carob header files) and the
*protocol* version (communication between carob and the controller)
somehow in a simple and elegant way.
Any ideas?
Regards,
Csaba
PS:
1. the same applies also for libmysequoia. Currently libmysequoia is
following the MySQL client interface. (12:0 for MySQL 4.0, 14:0 for
MySQL 4.1 and 15:0 for MySQL 5.0)
2. the life will be easier if Sequoia can fall back to an older
protocol if sees that we trying to connect with an old protocol. This
raises a lot of work and a lot of questions also :-)
Documentation:
http://www.linuxshowcase.org/2000/2000papers/papers/browndavid/browndavid_html/
http://sources.redhat.com/autobook/autobook/autobook_91.html
http://apr.apache.org/versioning.html
_______________________________________________
Carob mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/carob
_______________________________________________
Carob mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/carob
