From: Antonio Gallardo [mailto:[EMAIL PROTECTED] > Reinhard Poetz dijo: > > > >> From: Bruno Dumon > > > >> > Carsten made a good proposal how we can continue having 3 > >> repositories > >> > and how this can be done with only little code duplicating: > >> > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106076740711234&w= > >> > 2 > >> > > >> > I'm +1 with his proposal - the reason is simple: Some people (and > >> customers too!) asked me if we have gone crazy and how they can > >> update > >> > Cocoon in the future without being alpha/beta-tester for > >> 'real' blocks > >> > and Fortress. We *must* be able to maintain 2.1 without all new > >> features like blocks and Fortress because IMNSHO these > steps are to > >> big for 2.1 and I'm -1 on the changes in the current repository. > >> > >> I'm also +1 for starting a new repository, but I don't > like Carsten's > >> proposal that much. I'd rather see the entire repository > duplicated, > >> and move all development effort to the 2.2 repository. > Only bugfixes > >> should be applied to the 2.1 repository, and occasional > backports of > >> new functionality if anyone wants to. > > > > > > Let's look which new features are planned for the next time > and when > > they will be ready for beta and for final release? > > > > - real blocks > > - virtual sitemap components > > - intercepted flowscript > > - use Fortress as container > > - Cocoon Forms (aka Woody) > > - Cocoon Portals (new portal block) > > > > IMO the first four items should be part of 2.2 but the two > last items > > should be released earlier. Let's assume a szenario that the > > implementation of them takes very long (e.g. more than a > year until we > > reach a stable version). Do you really want to wait with > Cocoon Forms > > and Cocoon Portals such a long time (not to mention the many other > > blocks)? You can say now that you develop under 2.2 and you do > > occasional backports but IMO the problem is that e.g. > Cocoon Forms is > > tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable > > branch! Additionally we get a great mess with all our > blocks if they > > are duplicated, some are backported, some not and we > developers have > > to do a lot of work twice, work which is not real fun. > > > > That's the reason why I'm +1 with Carstens proposal: > > > > - 2.1 repository containing all our blocks > > - 2.2 repository contains only the new stuff introduced by > the first > > four points from above > > - the 2.2 build mechanism is 'clever' enough to get all sources > > from 2.1 that are missing > > > > What do you think? > > I think your proposal is OK. I was thinking for a while about > this and for my point of view the 2.2 is a major relase > (maybe it would be called 3.0). These 4 key points are a > radical change of how we can see at cocoon. > > And as you pointed we can start the block construction and > continue the improvement of the current 2.1 branch (in forms > and portal) while starting a total new cocoon. > > Of course the user interface will be preserved the most.
Yes, the external contracts (must) remain mainly stable: - the use of the sitemap and it's components - cocoon.xconf - hot to implement your custom components I think moving from 2.1 to 2.2(3.0) will not be more difficult (maybe easier) than moving from 2.0 to 2.1 which takes you a few hours. And IIUC the changes from the old to the new cocoon.xconf which is necessary for Fortress can be done automatically with a stylesheet. (This brings me to the point that we should publish which are our stable and external interfaces ...) > But > from the internals these is really a great new shaking if the > current code. > > Is this correct? I expect this and that's the reason why I think that a stable 2.2 release will take some time (I think that's not a matter of a few months but much more) and why I like Carsten's proposal. Reinhard > Best Regards, > > Antonio Gallardo > >
