cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agsoftware.dnsalias.com>
Subject RE: on better release and version management
Date Thu, 11 Sep 2003 10:19:58 GMT
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. But from the
internals these is really a great new shaking if the current code.

Is this correct?

Best Regards,

Antonio Gallardo




Mime
View raw message