cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: [2.2] Using includes in the sitemap for components?
Date Sun, 04 Sep 2005 19:53:40 GMT
Daniel Fagerstrom wrote:
> Upayavira wrote:
> ...
> 
>> I couldn't agree more. Personally I'd be -1 on porting ECM++ back to 
>> 2.1.x. 2.1.x should be a _maintenance_ branch, and unless we can focus 
>> on getting 2.2 out in some form, we risk some serious geopardy for our 
>> community, I think.
> 
> 
> +1
> 
>> So, let's release 2.2,  make that the main branch,
> 
> 
> +1
> 
>> and start adding OSGi, Maven, etc, into 2.3.
> 
> 
> -1
> 
> IMO, branching haven't done much god for our community this far, so I 
> can't see why we should repeat our previous mistakes.
> 
> OSGi and block development has this far been done in parallell with the 
> "classic" Cocoon development. AFAIK it hasn't disturbed anything else in 
> trunk this far and I don't think it will in the near future either.
> 
> It might happen, (although I doubt it), that we need a branch during 
> some part of the blocks development. If that happens, we can create a 
> branch then. But in that case we should have a really good plan about 
> how to make that branch short lived and possible to merge back in trunk 
> within a very limited time span.
> 
> Just creating a 2.3 or 3.0 branch because we feel that we might need it 
> and as we have made it before would IMO be a completely unnecessary 
> waste of community resources.
> 
> Now, due to license issues we cannot release any OSGi dependent code 
> until we have updated to OSGi R4, but that only means that we need to 
> make sure that classic Cocoon not depend on OSGi APIs and that we 
> exclude the OSGi stuff from the releases. This is probably a good thing 
> to do anyway, and very little work comparing to keep two branches 
> synchronized.
> 
>> With Carsten's proposal to release every two months, we're almost back 
>> into release early, release often, but, problem is, we'd be releasing 
>> a branch often, which is seriously broken, IMO.
>>
>> I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just 
>> after the GetTogether.
> 
> 
> +1
> 
> When the OSGi stuff are changed to R4 and is usefull enough we can start 
> to include it within 2.2.x releases for early adaptors. And when it is 
> stable enough and we have all infrastructure in terms of block 
> repositories, deploy tools, build system etc in place, we can remove the 
> "classic" way and release a 3.0.
> 
>                  --- o0o ---
> 
> Remember, open source code becomes stable when many people use it. 
> Creating development branches destabilizes the code as much fewer, if 
> any people, use it. And after having destabilized it, it takes much 
> resources and time to get it releasable again, and at the same time we 
> have to support the old stable release. All this is a frustrating and a 
> huge waste of resources, with no particular gain.
> 
> So, let us stop the branching madness and work towards having only *one* 
>  common branch (the trunk), that we do the releases from.

I'm quite happy with this approach.

Upayavira


Mime
View raw message