cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [2.2] Using includes in the sitemap for components?
Date Mon, 05 Sep 2005 05:51:02 GMT
Upayavira wrote:
> 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.

me too!

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message