2.0rc7 -> 2.0 in two weeks

I have checked in a revision mark and a clarification about
the sensitivity 
(that slipped the 2.0rc5 editing cycle). Thus we are ready
to put out 2.0rc7
which we will do as soon as we get around (in the next
days).

If no-one raises a serious objection, 
we will declare 2.0rc7 to be 2.0 after about 2 weeks.

This is overdue in my opinion. 
Given that several clients sucessfully implement the storage
format
for many years I believe the format in itself is a success
and the version number should reflect the actual stability
of the 
specification.

Of course: We will improve the specification at some point,

but this should not be under the 2.0 label. 
We could issue fixes 2.0.1 and work on 2.1 if we like.

Best,
Bernhard

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

_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format

Hello Bernhard,

On Friday, 18. April 2008 11:25:55 Bernhard Reiter wrote:
> I have checked in a revision mark and a clarification
about the sensitivity
> (that slipped the 2.0rc5 editing cycle). Thus we are
ready to put out
> 2.0rc7 which we will do as soon as we get around (in
the next days).
>
> If no-one raises a serious objection,
> we will declare 2.0rc7 to be 2.0 after about 2 weeks.
>
> This is overdue in my opinion.
> Given that several clients sucessfully implement the
storage format
> for many years I believe the format in itself is a
success
> and the version number should reflect the actual
stability of the
> specification.

Thanks for commiting the gender field change!

I'm currently fixing Horde's "categories" handling
and noticed that multi 
value fields like "children" don't define a
separator. <categories> already 
uses ",", so should we add a generic note that
multi value fields
get separated by ',' to be on the safe side?

I'm still wondering about the decision to use a separator
for multi value 
fields instead of an own XML tag per value, f.e.

<category>private</category>
<category>company</category>

instead of 

<categories>private, company</categories>

Thomas

_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format

Hi Thomas,

On Friday 18 April 2008 11:51, Thomas Jarosch wrote:
> I'm currently fixing Horde's "categories"
handling and noticed that multi
> value fields like "children" don't define a
separator. <categories> already
> uses ",", so should we add a generic note
that multi value fields
> get separated by ',' to be on the safe side?

we should make a list of multi value fields first.
IMO I am unsure about the nature of <children>, this
could contain other
statements about the children like: "Yes, three. All
boys".

> I'm still wondering about the decision to use a
separator for multi value
> fields instead of an own XML tag per value, f.e.
>
> <category>private</category>
> <category>company</category>
>
> instead of
>
> <categories>private, company</categories>

According to our CVS history, this was in there from the
beginning.
I don't know who added it, maybe Bo.
For Categories, it might just have been simpler.

Best,
Bernhard
-- 
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

_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format

Hi Bernhard,

> If no-one raises a serious objection,
> we will declare 2.0rc7 to be 2.0 after about 2 weeks.

This is excellent news.

Will he version number in the XML generated objects have to
change to 2.0 or
will it stay 1.0. I think the changes that where made where
more for
clarification that actual format changes.

Best Regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joonradleys.co.za
Web: www.toltec.co.za

> -----Original Message-----
> From: kolab-format-bounceskolab.org
[mailto:kolab-format-
> bounceskolab.org] On Behalf Of Bernhard Reiter
> Sent: Friday, April 18, 2008 11:26 AM
> To: kolab-formatkolab.org
> Subject: 2.0rc7 -> 2.0 in two weeks
> 
> I have checked in a revision mark and a clarification
about the
> sensitivity (that slipped the 2.0rc5 editing cycle).
Thus we are ready
> to put out 2.0rc7 which we will do as soon as we get
around (in the
> next days).
> 
> If no-one raises a serious objection,
> we will declare 2.0rc7 to be 2.0 after about 2 weeks.
> 
> This is overdue in my opinion.
> Given that several clients sucessfully implement the
storage format for
> many years I believe the format in itself is a success
and the version
> number should reflect the actual stability of the
specification.
> 
> Of course: We will improve the specification at some
point, but this
> should not be under the 2.0 label.
> We could issue fixes 2.0.1 and work on 2.1 if we like.
> 
> Best,
> Bernhard
> 
> --
> 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

_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format

Hi Joon,

On Friday 18 April 2008 15:43, Joon Radley wrote:
> > If no-one raises a serious objection,
> > we will declare 2.0rc7 to be 2.0 after about 2
weeks.
>
> This is excellent news.
>
> Will he version number in the XML generated objects
have to change to 2.0
> or will it stay 1.0. I think the changes that where
made where more for
> clarification that actual format changes.

a good question, you are refering to

  1.2. XML format description
[..]
  The version attribute denotes the version of this
specification. Until a 
  stable version is released, the number "1.0" is
used.

You are right: We should clarify this.

Hmmm, actually there were a few minor changes over the time,

so I think it would be reasonable to stick with the idea of
using 2.0 now.
Otherwise we could decouple the version number of the type
from the version
number of the specification and just keep the
"1.0" until we hit an 
incompatible change. I tend to at least upgrade to
"2.0". Shouldn't be a 
large problem as implementor would have considered this
"feature" for a 
while.

What do you all think?

Bernhard

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

_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format

Hi Joon,

On Friday 18 April 2008 17:12, Bernhard Reiter wrote:
> Hmmm, actually there were a few minor changes over the
time,
> so I think it would be reasonable to stick with the
idea of using 2.0 now.
> Otherwise we could decouple the version number of the
type from the version
> number of the specification and just keep the
"1.0" until we hit an
> incompatible change. I tend to at least upgrade to
"2.0". Shouldn't be a
> large problem as implementor would have considered this
"feature" for a
> while.
>
> What do you all think?

we (Ludwig) did a quick test with
KDE Kolab Client Proko2, enterprise35, Horde and Toltec
2.2.0 (we happend to 
have this on one testing machine).

events:
s/<event version="1.0" >/<event
version="2.0" >
contacts:
s/<contact version=1.0" >/<contact
version="2.0">

the only problem was there with Toltec which did not display
the objects.
Joon, can you confirm?

If so, this would be an argument for keeping "1.0"
in the upcoming 2.0 
spec. 

Best,
Bernhard
-- 
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

_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format

Hi Joon,

On Wednesday 30 April 2008 18:47, Joon Radley wrote:
> We do a version check on the Kolab-XML and any version
we do not understand
> Toltec rejects. I thought that was the whole point of
putting the version
> in the Kolab-XML object 

sure it is, but ... 

Seriously from the spec somebody would assume and =1.0 and
=2.0 would both be 
recoginised. Otherwise we never could do the change. Do you
already have a 
version out that can do =2.0? 

what do you recomment regarding the release of the 2.0 spec?
Add a special 
paragraph for "transition"?

Best,
Bernhard


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

_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format

Hi,

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.

Bernhard

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

_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format