From: Bruno Dumon > On Thu, 2003-09-11 at 14:19, Reinhard Poetz wrote: > > From: Bruno Dumon [mailto:[EMAIL PROTECTED] > > > > <snip/> > > > > > I expect Woody to also take another year or so before it can > > > be considered stable (in terms of interfaces, not code). > > > > ... that long? I expected it to be stable sooner (end of > this year). > > What's open? (I already added this discussion point to > > http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon) > > > > for one thing, there's all the stuff Sylvain's been proposing > (namespaces mixing, expression language switch, various other > things, I'll try to make a list before the hackaton).
Steven pointed out when he was writing about blocks that the implementation is NOT the problem if we have the design. I think that after the GT2003 we all will have a much better understanding where we want to go to with Woody and implementation will be done very soon. Then I would try to finalize (= find stable contracts) Woody ASAP and release it with 2.1.x. > > <snip/> > > > > Anyhow, lots of stuff to think about, though it'd be nice if > > > we get some interim solution in the meantime so that we can > > > get started on 2.2. > > > > Yep, this interims solution is necessary and after reading > Geoff's and > > Steven's posts I changed my opinion because you are right that we > > can't force block developer's to be backward compatible. > > > > So what's our plan? From my POV it looks like: > > > > - create a 2.2 repository as copy (incl. history) of 2.1 > > including all the blocks (so if somebody changes 2.2 core > > in an incompatible way I see it if I monitor the changes > > of the block I'm interested in) > > yep > > > - 2.1core only receives bug-fixes (like 2.0) > > I'd judge that on a case-by-case basis, i.e. if someone wants > to backport a new 2.2 core feature to 2.1, that they simply > propose that on the list and if nobody disagrees, they can go ahead. +1 > > > - find consensus on "What's Cocoon core?" > > - find consensus on a road map (after we know where we want > > to go?) and having milestones and target dates > > (I know Cocoon is an OSS project and all those features and > > dates are never binding for anyone but we should give our > > user's a better overview about the project and when he/she > > can expect a new feature) Maybe this is a point for the GT? Steven? > > - block developer's decide if they want to develop on 2.1 or 2.2 > > or when they want to switch > > hmm, I think that every change made to 2.1 should also be > done to 2.2 (but not vice versa of course). It would be > strange that 2.1 has features that are not in 2.2. Ok, then we develop all our things in 2.2; what I want to see is more backports from 2.2 to 2.1 than backports from 2.1 to 2.0. If we consider Woody as stable I would really like to see it backported to 2.1 if 2.2 is not ready for prime time. This time it shouldn't be too difficult because our internal interfaces will not change so much as from 2.1 to 2.0 - at least I hope so ;) Then we have to decide if we need for every backport (not bugfix) a vote or not. What do you think? > > - when the block implementation of 2.2 is "useable" we can think > > about how we continue developing our real blocks (AFAIK > versioning > > is not a problem any more with real blocks) > > yep. > > > > > What do you think? > > I think we're almost there. Lets wait a few more days to give > others a chance to comment, and then launch a vote. fine, go ahead when you think it's time for it. Cheers, Reinhard
