Gilles Rayrat <[EMAIL PROTECTED]> writes:

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

Nice example.

The protocol can be seen as an interface and Sequoia can be seen as a
library which carob links to. So this issue is finally not very
different from numbering issues faced by most other projects which
link to external librairies.

I think everyone agrees here that the very first and most important
message carried by the version numbers of a library is related to the
compatibility of the _exported_ interface, and not related to imported
interfaces (here: sequoia).

On the other hand, it is tempting to advertise _both_, so it's true
something like carob-7.0_sequoia-2.7 is tempting.

But has anyone already seen something like: firefox-0.7_HTTPv1.1 ?

Nope, because... HTTP always "magically works" thanks to backward
compatibility which we don't have yet :-/


> 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

Yeah, they will probably wonder why numbers jump irrationally like
nothing they have seen before.

Worst: now imagine that you have some almost non-changing carob code
which is compatible with sequoia 4.5, 4.6, 5.0, 5.1 and 5.2. How would
number it? That is a big issue.



> And same for libmysequoia/odbsequoia...

Actually upper layers just need to state their compatibility against
carob versions, the compatibility with sequoia is only indirect.

They do not communicate directly with the controller and should not be
directly concerned about protocol issues.





_______________________________________________
Carob mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/carob

Reply via email to