You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ralph Goers <Ra...@dslextreme.com> on 2005/05/23 08:06:23 UTC
Re: Releasing 2.2
Bertrand Delacretaz wrote:
> Le 23 mai 05, à 07:13, Reinhard Poetz a écrit :
>
>> ...Let's release "Cocoon 2.2 alpha1" as soon as possible. When the
>> contracts are stable we use the "beta" postfix. This will increase
>> the number of people who use and test the release and finally we can
>> release "Cocoon 2.2.0 final"...
>
>
> Releasing 2.2 soon would allow us to stop keeping the 2.1 branch in
> sync, which is a pain IMHO.
Well, it will let us eventually do this, but I don't believe we will be
ready to drop support of 2.1 anytime soon. As a matter of fact, Leszek
provided a fix last week for what seems to me to be a pretty serious bug
in flow and this alone should warrant a 2.1.8 release.
>
> But are there enough visible incentives in 2.2 for people to make the
> switch? Do we have cool, exciting samples of the new features?
>
> I'm not sure, and if we haven't, people might just keep on using 2.1,
> and the risk is having too much pressure to maintain 2.1 instead of
> being able to move on.
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.
Ralph
Re: Releasing 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
I believe it is the bug you reported.
Paul Crabtree wrote:
>>As a matter of fact, Leszek
>>provided a fix last week for what seems to me to be a pretty serious bug
>>in flow and this alone should warrant a 2.1.8 release.
>>
>>
>
>Hi Ralph,
>
>We are about to go to production with an application built on 2.1.7
>that uses flow heavily. Could you point me in the direction of this
>bug that Leszek has fixed so i can work out whether we are affected.
>
>Regards, Paul.
>
>
Re: Releasing 2.2
Posted by Paul Crabtree <pa...@gmail.com>.
> As a matter of fact, Leszek
> provided a fix last week for what seems to me to be a pretty serious bug
> in flow and this alone should warrant a 2.1.8 release.
Hi Ralph,
We are about to go to production with an application built on 2.1.7
that uses flow heavily. Could you point me in the direction of this
bug that Leszek has fixed so i can work out whether we are affected.
Regards, Paul.
Re: Releasing 2.2
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
>Daniel Fagerstrom wrote:
>
>
>>That is a reason for increasing minor version, but not for maintaining
>>parallell branches for years.
>>
>>
>If we don't maintain the "old" 2.1.x branch, what about all its users?
>Do you want to force them to migrate to 2.2? That's simply not
>realistic. We should be able to provide bug fixes for all those out
>there using our project.
>
>
Have never disputed that we have to maintain 2.1 for some while and that
we must go the alpha->beta->stable cycle for 2.2.
My message is that I fail to see that we gained anything from creating
an unstable development branch and that we should avoid doing that
mistake in the future.
If we want to remove deprecated code, we have a routine for that: wait
long enough time, so that everyone have had the chance to do anything,
vote about it, remove the code and step up the minor number. If we at
that point feel that we still need to maintain the previous version, it
means that we removed the deprecated code to early and the we probably
should readd it and schedule the removal to the next minor release.
Mainteining two versions because of to early removal of deprecated code
seem like a bad idea.
For API changes the situation is obviously more complicated, so we must
really know what we are doing and if possible make it possible to use
the new and the old in parallell for some while.
If this can't be done, we need to maintain an old branch for a period.
But in this case we should try to decide for how long time we maintain
it and remove it afterwards. And it should IMO be marked as a
compability branch rather than the stable one.
IMO we should really try to let trunk contain the stable branch in the
future. The idea of an unstable development doesn't seem to fit well
with our *actual* community dynamics. And it doesn't fit well with agile
development methods either. And it is IMO highly questionable if it has
done anything good for us since 1.0->2.0. To me it rather seem to hurt us.
/Daniel
Re: Releasing 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>
> That is a reason for increasing minor version, but not for maintaining
> parallell branches for years.
>
If we don't maintain the "old" 2.1.x branch, what about all its users?
Do you want to force them to migrate to 2.2? That's simply not
realistic. We should be able to provide bug fixes for all those out
there using our project.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.2
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
>Daniel Fagerstrom wrote:
> --- 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.
>>
>>
>One of the main reasons for creating 2.2 are incompatible changes. We
>removed some deprecated api and stuff like that in 2.2;
>
That is a reason for increasing minor version, but not for maintaining
parallell branches for years.
/Daniel
Re: Releasing 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
--- 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.
>
One of the main reasons for creating 2.2 are incompatible changes. We
removed some deprecated api and stuff like that in 2.2; so it's not that
easy to just run an application for 2.1.x using 2.2 - you might be
affected by the changes. So we provide compatibility with 2.1.x. We give
the users the guaranty that they can safely update from 2.1.x to 2.1.x+1
(ok, there are exceptions to this rule).
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.2
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Releasing 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
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.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.2
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 23 mai 05, à 08:06, Ralph Goers a écrit :
> ...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...
And that's the big difference IMHO. Once we can say that 2.1 is
strictly in maintenance mode, with new features being added to 2.2
only, the syncing work would be much less.
But this means getting at least an alpha release of 2.2 out of the
door, I think.
-Bertrand