On Nov 13, 2008, at 12:41 AM, Guido Günther wrote:
Ah, o.k.! Having more frequent releases (even with small updates only)
is actually a great thing. Are there any release plans for 1.4 or even
2.0?
We're not doing any work on 1.x really other than security-type
fixes. That's mostly due to our priorities at Apple, which are all
gears at the 2.x (trunk) work.
I'd like to do a 2.x release, but the current code isn't stable
enough, I think for that yet. In particular, all of the work Cyrus
has been doing on what we call "implicit scheduling", is pretty major,
has only just recently landed in trunk, and needs some time and
testing to bake in.
Implicit scheduling is basically catching up to compliance with the
newest CalDAV-schedule draft specs, wherein the responsibility for
ensuring that scheduling (iTIP) messages are delivered properly is
moved from the clients to the server. I've been pushing for that
change for a long time, on the theory that:
• Clients screw things up more than servers[1]
• Updating broken scheduling code on a server is easy than updating
every client that uses the server.
• If any one of many client implementations is broken, it could
ruin the party for everyone.
• Even well-written clients can still be subtly incompatible, and
it's best for everyone on a server to share the same scheduling logic.
• It makes it a lot easier to write a CalDAV client, since you
don't have to implement the scheduling logic (unless you also want to
support iMIP)[2]
• It eliminates the requirement that the organizer's client be
running and passing messages along in order for attendees to know
what's going on.[2]
Morgen recently added support for outbound email invitations, and
we're still ironing out details there, so that needs al little time as
well.
That said, I think we'll probably have an increasingly stable trunk
again as the year winds down, and perhaps it'll make sense to tag a
2.0 (or maybe a preview?) in the new year.[4] Does that make sense?
-wsv
[1] OK, I'm totally biased. That one isn't really a valid point
[2] These are the most compelling from an end-user point-of-view[3]
[3] Assuming that no client or server bugs make the other items user-
visible, which is probably a stretch
[4] I should be more communicative about such thing here, I know. So,
thanks for asking.
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
