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
--------------------------------------------------------------------
