Re: [CalendarServer-dev] [CalendarServer-changes] [3245] CalendarServer/tags/release/CalendarServer-1.3/
Hi Winfredo, On Tue, Oct 28, 2008 at 11:21:32AM -0700, source_changes@macosforge.org wrote:
Revision: 3245 http://trac.macosforge.org/projects/calendarserver/changeset/3245 Author: wsanchez@apple.com Date: 2008-10-28 11:21:32 -0700 (Tue, 28 Oct 2008) Log Message: ----------- Tag 1.3. Small changes, but has been stable a while. Diffing 1.3 vs. 1.2 shows:
config.py |13628 ++++++++++++++++++++++++++++++++++++++++++++++++++ static.py |16712 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- are these the only changes scheduled for 1.3? -- Guido
On Oct 30, 2008, at 1:58 AM, Guido Günther wrote:
are these the only changes scheduled for 1.3?
Yeah, these are really small, but it's been sitting around a while, so I thought it made sense to cut a release and get them out. -wsv
On Mon, Nov 10, 2008 at 02:47:27PM -0800, Wilfredo Sánchez Vega wrote:
On Oct 30, 2008, at 1:58 AM, Guido Günther wrote:
are these the only changes scheduled for 1.3?
Yeah, these are really small, but it's been sitting around a while, so I thought it made sense to cut a release and get them out. 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? Cheers, -- Guido
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.
On 13.11.2008, at 19:33, Wilfredo Sánchez Vega wrote:
• 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]
FYI: in an Outlook scenario you most likely will always have iMIP for scheduling, or even worse, MAPI payloads (if the user doesn't manage to configure his Outlook to do iMIP). OpenSource tools exist to convert the latter on the mail server to regular MIME/iMIP. It would be very nice if MacOSX server would include those. (there are ways to hack around the scheduler-via-mail behaviour of Outlook, but those are not very convenient for the enduser for various reasons) [BTW: I'm not saying that the idea is bad, just that it won't help much with Outlook :-)] Thanks, Helge -- Helge Hess http://helgehess.eu/
On 13.11.2008, at 19:33, Wilfredo Sánchez Vega wrote:
Morgen recently added support for outbound email invitations, and we're still ironing out details there, so that needs al little time as well.
Ah, forgot this. For Outlook to recognize iMIP messages, they must not be embedded in a MIME structure. It has to be a plain iMIP message. Just for completeness :-) Thanks, Helge -- Helge Hess http://zideone.com/
On 13.11.2008, at 19:33, Wilfredo Sánchez Vega wrote:
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?
Ah, and a final question ... will 2.0 include CardDAV support? :-) Trunk does not seem to include anything like it? Thanks, Helge -- Helge Hess http://zideone.com/
On Thu, Nov 13, 2008 at 10:33:44AM -0800, Wilfredo Sánchez Vega wrote: [..snip..]
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? Yes, that sounds great! I'm more than happy to push frequent updates of release candidates into debian as the disk layout doesn't change anymore (or threre are tools for smooth upgrades available). Thanks for the explanation, -- Guido
On Nov 14, 2008, at 3:22 AM, Guido Günther wrote:
Yes, that sounds great! I'm more than happy to push frequent updates of release candidates into debian as the disk layout doesn't change anymore (or threre are tools for smooth upgrades available).
Yes, a requirement for 2.0 should be a smooth upgrade process from 1.x. -wsv
participants (3)
-
Guido Günther
-
Helge Heß
-
Wilfredo Sánchez Vega