2.0rc7 -> 2.0 in two weeks

Bernhard Reiter bernhard at intevation.de
Mon May 5 09:47:54 CEST 2008


On Sunday 04 May 2008 03:28, Joon Radley wrote:
> Adding support for the version 2.0 version number support is trivial.
> Changing the version number however entails and upgrade of _all_ Kolab
> clients on all client machines. This is a major investment for what amounts
> to a clarification of the original Kolab-XML 1.0 specification.

according to our quick test the change would hit Toltec.
(We did not test Konsec, nur Bynari.
And it always has been the Kolab-Storage-Format 2.0 specification. ;) )

> AFAIK all the clients are up to date with the current specification or very
> close to it, so changing the version number itself does not enforce
> anything.
> So we either must specify that version 2.0 is a completion of the 1.0
> specification without a version number change or provide a change over
> period for clients with the "2.0" version number support to be incorporated
> in the normal upgrade cycle.

I tend to go with the version=1.0 for the 2.0 specification, 
this deviates from the original idea, 
but I have doubts about the version=specification number.
It would need to hold for development, beta and release candiate versions
as well and there is the possibility of compatible changes. 
I propose to have a secion about compatibility in the document.


Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20080505/8e6184a0/attachment.sig>

More information about the format mailing list