Carsten Ziegeler wrote:
Ralph Goers wrote:
I doubt many will switch until 2.2 is stable - i.e we've had a few
releases of it. I would recommend that we continue doing maintenance on
2.1 until at least a stable 2.2.0 is released and possibly a release or
two later. That doesn't mean that new features need to be backported to
2.1 though.
Exactly. It took a long time until the majority updated from 2.0 to 2.1;
and still there are many installations out there using 2.0.x. So we have
to maintain 2.1.x for a long time.
But as soon as 2.2 is final we don't have to sync the branches anymore,
just for bugfixes.
I think you are mixing cause and effect: 2.1 and now 2.2 become unstable
because we *let* them become unstable. We removed them from extensive
user testing and feedback by marking them usstable. And user testing and
feedback is the only thing that creates *real* stability. As developer
your testing is always limited to your own prejudices about what the
feature should be used for.
By marking the 2.1 and 2.2 unstable we also created the impression that
it is ok to add new features without discussions and tests and that
someone else will take care of the problems later. Also it creates
discontinuity, people avoid going 2.0->2.1 and 2.1->2.2 because so many
changes has been allowed to add up during the years between the minor
releases, so that it will require a lot of work to port.
As we have let this happen for 2.2 we must of course maintain 2.1 for a
while and go through an alpha->beta->stable cycle for 2.2. But I really
think we should avoid this mess in the future.
--- o0o ---
So lets evaluate what we have gained by spliting in a 2.1 and 2.2
branch. It was supposed to be necessary for developing "real blocks", I
don't see that it has helped us and I fail to see why it should be
necessary. And as being active in this area I should know at least
somthing about it.
If we take a look on what is new in 2.2, we copied the ECM to the Cocoon
repository and changed the package names. I don't think that introcuced
any instabillity. After that there have been various refactorings of
ECM. If these have introduced back incompabilities, there should have
been votes about it, if there hasn't been votes it rather shows that it
is dangerous to have a "playground" branch.
I don't think that the introduction of includes in cocoon.xconf, lazy
loading of components, local classpath for sitemaps, or hosting of other
IoC containers (see
http://www.anyware-tech.com/blogs/sylvain/archives/000171.html) should
have caused any incompability or instability for those not using it.
For those things I have been involved in: JXTG refactoring was done
without disturbing uses of the original one until the community felt
confident with switching. The same process could have been followed in a
stable branch. And we probably would have got more testing as the ablity
to use it without flow is a feature that several users have asked for.
VPCs have not affected existing functionality, they could actually even
have been developed in an own block.
My work on "Sitemap blocks" haven't affected any existing functionality
either and can be moved to a block if we want.
--- o0o ---
Probably I'm missing important aspects, but I fail to see what the split
into trunk and stable have bought us, except for less testing,
disruption and possibly sloopier coding as the branch is supposed to be
unstable anyway.
/Daniel
