cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [2.2] Using includes in the sitemap for components?
Date Sun, 04 Sep 2005 18:17:40 GMT
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.

/Daniel

Mime
View raw message