You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2005/05/22 12:46:08 UTC
[RT] Releases
(was: [RT] Micro kernel based Cocoon)
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
<snip/>
>> We should move 2.2 out the
>> door as soon as possible and target "real blocks" for a later release.
>> So, try out OSGi if you want, but please not in the trunk.
<snip/>
> And AFAIU it's out of discussion that the OSGi layer will be part of
> Cocoon 2.2 - although it would be helpful to define what Cocoon 2.2 will
> be in order to get it out - in the past all my efforts to reach a common
> understanding were not very successful :-(
AFAIU our current release and "project management policy" is based on:
* Reaching a common understanding on what should pe part of a specific
release.
* Document this in the Wiki or even better in Bugzilla.
* Finish all the tasks.
* Have a period of testing.
* Release it.
This all looks like a traditional and responsible way of doing things.
But except for some short bursts of activity when one or a few people
have felt strong enough itch to lead such a process, it is rather far
away from our everyday business.
The work that actually gets done is based on that someone have a strong
enough itch, and rather seldom on some central planning.
To illustrate that our current understanding of releases doesn't fit the
community dynamics we actually have, you can take a look at
http://wiki.apache.org/cocoon/22Planning and
http://issues.apache.org/bugzilla/showdependencytree.cgi?id=25322 and
ask yourself which points you actually are going to contribute coding in
the next few months.
Since 2000 we have managed to ship a handfull of 2.0 and a handfull of
2.1 releases. Considering the amount of activity and the volume and
quality of what have done during that period it must be a hard to beat
record in conservative version numbering ;)
--- o0o ---
IMO we should find a less demanding and more realistic attitude for
Cocoon releases, so that we can go towards "release early, release often".
Planning what should be part of the next major release seem harmfull, as
the relase can stall forever if there is a difference between what we
would like to have in the release and what we actually are implementing.
--- o0o ---
IMO we should *only* work at trunk. No "stable" branches, we should
instead making sure that core functionality always is stable, and find
incremental ways for changing core functionality.
If we, after having voted about it, introduce back incompability, it
means that the next release should go from 2.1.x to 2.2.0 e.g. It
shouldn't be a greater deal than so. We can also step up the version
because we feel that we want to marketing some important addition.
We should base our releases on what we actually have done rather on what
we wish that someone else should develop.
--- o0o ---
For our current situation I think we could release a 2.2.0 right away.
It doesn't contain what we planned for but OTH it contains a lot of
goodies that we didin't plan for and that should be usefull for a larger
audience.
When/if we finish the blocksl, or some other important stuff we can
release 2.3 or even 3.0 if we feel like it.
--- o0o ---
I haven't made much release related work in the past and its far from my
number one itch right now, so this take this semi rant for what it is.
But IMO we should stop this wishfull thinking based "major next version"
nonsense, sooner rahter than later. And also stop difussing our energy
in pointless branching.
We should be proud of what we *actually* achieve, and step up the first
decimal as soon as we have added some important feature.
/Daniel
Re: [RT] Releases
Posted by Ralph Goers <Ra...@dslextreme.com>.
Niclas Hedhman wrote:
>Listen to the founding fathers of this project, who declared (and lived by it
>in the 1.x days) "Release Early, Release Often". Everyone here talks about
>it, but doesn't live by it.
>
>
I have no problem with release early, release often. I just have a
problem with code instability. I believe that 2.1.6 and 2.1.7 are more
stable, in general, than the earliest 2.1.x releases, despite some new
features being added. However, that is a far cry from where we'd be if
some of the things that are in 2.2 had been added to 2.1 in a
maintenance release.
>
>Cheers
>Niclas
>
>
>
Re: [RT] Releases
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 23 May 2005 14:18, Ralph Goers wrote:
> Is this your perception of just Cocoon or all open source development.
I would say all software development. IMHO, frequent smaller changes is by far
a much more effective way to progress a codebase. The longer the cycle, the
more important your points below becomes.
> When I release my product I don't want to have update the
> framework every two weeks. And if there is a bug, the next release
> probably won't be any better. Sure the bug might have been fixed, but
> now will just have new ones because of all the new stuff.
This is the typical argument against "frequent releases".
I happen to disagree that next release won't be any better, because of new
bugs. If it is worse, then the people behind the product is careless. New
bugs have a strong tendency to appear in new code (refactorings included),
mostly not because smaller fixes of found problems.
> But until this is accomplished I am not in favor of creating an
> unstable codebase.
Of course noone is in favour of creating a unstable codebase
_of_what_is_being_used_.
Take Ant as an example of fairly good release management (cycles slightly
longer than I would like, esp 1.6.2 -> 1.6.3, but still...)
The 1.6 branch has had 5 releases in ~ a year and half. In those releases, the
1.7 features are added along side with bug fixes. The 1.7 features have had
quite a lot of bugs (relatively speaking). Does that make Ant 1.6 unstable??
IMO, not at all. Do you have a problem using the latest Ant, without extensive
internal testing? I don't think you have a problem.
What is expected to work, works. The new stuff is somewhat shaky. Typical for
software evolution.
Cocoon is strange, since so called 2.2 features were 'back ported' to 2.1, to
a point where even some experts here is not sure what 2.2 is actually
offering over 2.1. Doesn't this make 2.1 unstable as well, then?
Suggestion; Try it. If it doesn't work, you can always go back. And if it
makes you feel better, put some large disclaimers on the parts that you think
is unstable.
Listen to the founding fathers of this project, who declared (and lived by it
in the 1.x days) "Release Early, Release Often". Everyone here talks about
it, but doesn't live by it.
Cheers
Niclas
Re: [RT] Releases
Posted by Ralph Goers <Ra...@dslextreme.com>.
Niclas Hedhman wrote:
>Cocoon community is IMHO too focused of NOT releasing something BAD, instead
>of focusing on releasing the new and good stuff.
>If releases came out on a bi-weekly basis, who would be worried that a bug or
>two sneaked in. Patch and it will be fixed in days. And with so many
>community members having sites deployed off the HEAD, I doubt that much
>regression would occur in reality, and committer sensibility is another
>'safety net'.
>
>
> My two cents.
Is this your perception of just Cocoon or all open source development.
What you are suggesting is unacceptable for use in a production
environment. When I release my product I don't want to have update the
framework every two weeks. And if there is a bug, the next release
probably won't be any better. Sure the bug might have been fixed, but
now will just have new ones because of all the new stuff. When you
deploy your production application on Tomcat or JBoss just how often are
you updating your container? We do it only when we have a new release
of our product coming out. We expect the frameworks we use to be
stable. And Cocoon is just another container just like Tomcat or JBoss.
I, for one don't deploy from head. I pick a stable release and use that
and then apply any patches I need to it after extensively testing.
>By trying to minimize(!) the number of new features in each 2.x.0 release, the
>users have less learning to cope with, when 'inhaling' a new feature release.
>Going from 2.0 to 2.1 or 2.1 to 2.2 is overwhelming, especially if you have
>not followed the dev-list.
>
>
This is a problem because the Cocoon "core" (i.e. - practically
everthing) is too big. "Real blocks" are the answer, not changes to
release management.
>Further down the road, breaking codebase system apart, allowing individual
>release cycles for core vs each block should also help in shortening the
>cycle.
>
>
Here I absolutely agree. But until this is accomplished I am not in
favor of creating an unstable codebase.
>"Ok to release?"
>"yeah, yeah, yeah."
>"I'll do it!"
>
>./release.sh 2.5.1[enter]
>
>done.
>
>
>Cheers
>Niclas
>
>
Ralph
Re: [RT] Releases
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 23 May 2005 02:32, Daniel Fagerstrom wrote:
> Hmm, that is to overdo it IMO. Plans and todo lists and Bugzilla entries
> can be very usefull for knowing what is left todo, weak points etc. The
> problem is when we put together a number of todo lists and say that they
> constitute the next minor version, it works for companies but it just
> doesn't seem to work for a volontary project like our.
My two cents.
Cocoon community is IMHO too focused of NOT releasing something BAD, instead
of focusing on releasing the new and good stuff.
If releases came out on a bi-weekly basis, who would be worried that a bug or
two sneaked in. Patch and it will be fixed in days. And with so many
community members having sites deployed off the HEAD, I doubt that much
regression would occur in reality, and committer sensibility is another
'safety net'.
By trying to minimize(!) the number of new features in each 2.x.0 release, the
users have less learning to cope with, when 'inhaling' a new feature release.
Going from 2.0 to 2.1 or 2.1 to 2.2 is overwhelming, especially if you have
not followed the dev-list.
Further down the road, breaking codebase system apart, allowing individual
release cycles for core vs each block should also help in shortening the
cycle.
"Ok to release?"
"yeah, yeah, yeah."
"I'll do it!"
./release.sh 2.5.1[enter]
done.
Cheers
Niclas
Re: [RT] Releases
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> IMO we should find a less demanding and more realistic attitude for
>> Cocoon releases, so that we can go towards "release early, release
>> often".
>>
>> Planning what should be part of the next major release seem harmfull,
>> as the relase can stall forever if there is a difference between what
>> we would like to have in the release and what we actually are
>> implementing.
>
> yes, that's my conclusion too. (For now I will stop to write any plans
> or enter bugzilla entries.)
Hmm, that is to overdo it IMO. Plans and todo lists and Bugzilla entries
can be very usefull for knowing what is left todo, weak points etc. The
problem is when we put together a number of todo lists and say that they
constitute the next minor version, it works for companies but it just
doesn't seem to work for a volontary project like our.
/Daniel
Re: [RT] Releases
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> (was: [RT] Micro kernel based Cocoon)
> Reinhard Poetz wrote:
>
>> Carsten Ziegeler wrote:
>
> <snip/>
>
>>> We should move 2.2 out the
>>> door as soon as possible and target "real blocks" for a later release.
>>> So, try out OSGi if you want, but please not in the trunk.
>
> <snip/>
>
>> And AFAIU it's out of discussion that the OSGi layer will be part of
>> Cocoon 2.2 - although it would be helpful to define what Cocoon 2.2
>> will be in order to get it out - in the past all my efforts to reach a
>> common understanding were not very successful :-(
>
>
> AFAIU our current release and "project management policy" is based on:
>
> * Reaching a common understanding on what should pe part of a specific
> release.
> * Document this in the Wiki or even better in Bugzilla.
> * Finish all the tasks.
> * Have a period of testing.
> * Release it.
>
> This all looks like a traditional and responsible way of doing things.
> But except for some short bursts of activity when one or a few people
> have felt strong enough itch to lead such a process, it is rather far
> away from our everyday business.
>
> The work that actually gets done is based on that someone have a strong
> enough itch, and rather seldom on some central planning.
>
> To illustrate that our current understanding of releases doesn't fit the
> community dynamics we actually have, you can take a look at
> http://wiki.apache.org/cocoon/22Planning and
> http://issues.apache.org/bugzilla/showdependencytree.cgi?id=25322 and
> ask yourself which points you actually are going to contribute coding in
> the next few months.
>
> Since 2000 we have managed to ship a handfull of 2.0 and a handfull of
> 2.1 releases. Considering the amount of activity and the volume and
> quality of what have done during that period it must be a hard to beat
> record in conservative version numbering ;)
yes, this also gives people that don't follow the mailing list the impression,
that Cocoon isn't an agile project.
>
> --- o0o ---
>
> IMO we should find a less demanding and more realistic attitude for
> Cocoon releases, so that we can go towards "release early, release often".
>
> Planning what should be part of the next major release seem harmfull, as
> the relase can stall forever if there is a difference between what we
> would like to have in the release and what we actually are implementing.
yes, that's my conclusion too. (For now I will stop to write any plans or enter
bugzilla entries.)
>
> --- o0o ---
>
> IMO we should *only* work at trunk. No "stable" branches, we should
> instead making sure that core functionality always is stable, and find
> incremental ways for changing core functionality.
>
> If we, after having voted about it, introduce back incompability, it
> means that the next release should go from 2.1.x to 2.2.0 e.g. It
> shouldn't be a greater deal than so. We can also step up the version
> because we feel that we want to marketing some important addition.
>
> We should base our releases on what we actually have done rather on what
> we wish that someone else should develop.
I agree
>
> --- o0o ---
>
> For our current situation I think we could release a 2.2.0 right away.
> It doesn't contain what we planned for but OTH it contains a lot of
> goodies that we didin't plan for and that should be usefull for a larger
> audience.
yes
>
> When/if we finish the blocksl, or some other important stuff we can
> release 2.3 or even 3.0 if we feel like it.
>
> --- o0o ---
>
> I haven't made much release related work in the past and its far from my
> number one itch right now, so this take this semi rant for what it is.
>
> But IMO we should stop this wishfull thinking based "major next version"
> nonsense, sooner rahter than later. And also stop difussing our energy
> in pointless branching.
>
> We should be proud of what we *actually* achieve, and step up the first
> decimal as soon as we have added some important feature.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT] Releases
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
> For our current situation I think we could release a 2.2.0 right away.
JFYI, seems like 2.2 is largely unusable / unstable ATM:
WARN (2005-05-19) 13:16.31:159 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM
during lookup.
WARN (2005-05-19) 13:16.31:450 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM
during lookup.
WARN (2005-05-19) 13:16.32:441 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM
during lookup.
WARN (2005-05-19) 13:16.32:842 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM
during lookup.
WARN (2005-05-19) 13:16.33:092 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM
during lookup.
WARN (2005-05-19) 13:16.33:262 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: ComponentLocator exception from parent SM
during lookup.
WARN (2005-05-19) 13:16.39:061 [core.manager] (/)
PoolThread-4/CoreServiceManager: ComponentLocator exception from parent SM
during lookup.
WARN (2005-05-19) 13:16.39:592 [core.manager] (/)
PoolThread-4/CoreServiceManager: ComponentLocator exception from parent SM
during lookup.
WARN (2005-05-19) 13:16.46:512 [core.manager] (/samples/blocks/)
PoolThread-4/CoreServiceManager: ComponentLocator exception from parent SM
during lookup.
WARN (2005-05-19) 13:18.09:471 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo]
WARN (2005-05-19) 13:18.09:471 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo]
WARN (2005-05-19) 13:18.09:471 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo]
WARN (2005-05-19) 13:18.09:471 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo]
WARN (2005-05-19) 13:18.09:551 [core.manager] (Unknown-URI)
Unknown-Thread/AbstractFactoryHandler: Error decommissioning component:
org.apache.cocoon.components.store.impl.EHDefaultStore
WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.forms.expression.ExpressionManager]
WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.excalibur.source.SourceResolver]
WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.components.classloader.ClassLoaderManager]
WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.forms.datatype.DatatypeManager]
WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.forms.CacheManager]
WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.forms.validation.WidgetValidatorBuilderSelector]
WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.components.treeprocessor.ProcessorComponentInfo]
WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.forms.event.WidgetListenerBuilderSelector]
WARN (2005-05-19) 13:18.09:561 [core.manager] (Unknown-URI)
Unknown-Thread/CoreServiceManager: disposing of handler for unreleased
component. role [org.apache.cocoon.forms.FormManager]
Vadim
Re: [RT] Releases
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> Don't know. Reinhard and maybe Sylvain at least seem to use it for
>> customer systems maybe there are more.
>
>
> Yes, it's my plan to use trunk for my current customer application
> because I want to use the new jxtemplate implementation and the
> per-sitemap-classloader that makes development so much easier.
>
> As my application will be used in a high-traffic application, expect
> some stress tests in the next weeks. From my recent jxtemplate tests I
> have the sense that trunk performs very well.
Would you have time to compare old and new JXTG implementation?
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [RT] Releases
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Don't know. Reinhard and maybe Sylvain at least seem to use it for
> customer systems maybe there are more.
Yes, it's my plan to use trunk for my current customer application because I
want to use the new jxtemplate implementation and the per-sitemap-classloader
that makes development so much easier.
As my application will be used in a high-traffic application, expect some stress
tests in the next weeks. From my recent jxtemplate tests I have the sense that
trunk performs very well.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT] Releases
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Ralph Goers wrote:
>
>> Daniel Fagerstrom wrote:
>
>>> For our current situation I think we could release a 2.2.0 right
>>> away. It doesn't contain what we planned for but OTH it contains a
>>> lot of goodies that we didin't plan for and that should be usefull
>>> for a larger audience.
>>
>>
>> Disagree.
>> First, I want to see Cocoon Forms marked stable, even if the next
>> release is 2.1.8, IMO that has got to happen.
>
>
> We all want to see Cocoon Forms marked stable. But most of us, I for
> example, don't do anything to make it happen.
And I go into the bad behavior of adding new features...
>> Second, has anybody stress tested trunk? Or documented what
>> incompatibilities have been introduced? Or even what features it
>> provides?
>
>
> Don't know. Reinhard and maybe Sylvain at least seem to use it for
> customer systems maybe there are more.
I use 2.2 for some prototypes, but not for customer projects.
>> Heck, if someone asked me what the benefit of the current trunk is
>> over the 2.1.X branch I don't think I could tell them. I know the
>> core has changed a lot....
>
>
> This is the most popular reference:
> http://www.anyware-tech.com/blogs/sylvain/archives/000171.html
That was to outline all of the hidden gems that were flourishing in trunk...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [RT] Releases
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Ralph Goers wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> Planning what should be part of the next major release seem harmfull,
>> as the relase can stall forever if there is a difference between what
>> we would like to have in the release and what we actually are
>> implementing.
>
>
> I don't think I understand. Or maybe I do. It sounds like you just
> want to do stuff and release with no community discussion over the
> direction Cocoon should go.
Most definitively not. It should be rather clear from my activities on
the list that I find community discussions and votes being of
fundamental importance.
What I oppose is the current practice to say that the features so and so
are required before we can relase version X.Y and then letting it stall
for ever because this set of "nice to have" wasn't important enough for
anyone to actually implement it.
OTH people, hopefully after community discussions, introduce new usefull
stuff all the time. We should IMO be more realistic and base our relases
and numbering on what actually become implemented.
> However, I agree that just discussing
> endlessly is pretty useless. But planning is a good thing - even if it
> just means saying "no your enhancement cannot go in the next release
> because it breaks incompatibility, but it can go in the following one if
> we provide warning now".
Exactly. Planning and even wishfull thinking are good things. But we
shouldn't let our release schedule be to dependent on wishfull thinking ;)
>> --- o0o ---
>>
>> IMO we should *only* work at trunk. No "stable" branches, we should
>> instead making sure that core functionality always is stable, and find
>> incremental ways for changing core functionality.
>
> Absolutely disagree. Stable branches are required so that you can
> maintain a stable delivery at all times. 2.1 is doing very well in that
> regard.
IMO we should be able to create a stable delivery from trunk at all
times. Cocoon contains a lot of stuff, some of it is in heavy use and
have been part of Cocoon for a long time. When refactoring and adding
features to these parts utermost care and testing is IMO always a
requirement. OTH there are many things, also in 2.1.x that is in early
stages of develpment, isn't tested or have few or no users.
I doubt that it is meanifull to talk about something as large as Cocoon
as "stable" or "unstable" as it by its nature must have parts in
different stages of stabilty at all times. This is one reason that I
find it so important to split Cocoon in blocks (or bundles). Then we get
small enough unities to be able to talk about stability at bundle level.
When we have branched Cocoon it has always been motivated with the need
to experiment and being allowed to let core stuff be unstable for an
extended period. But in retrorespect I wonder if this rally have given
us that much. For 1.0->2.0, sure but after that?
> I cannot see how we could move to an architecture that supports
> real blocks in an incrementatl fashion while maintaining the stability
> we need to provide our customers.
The plans that I have proposed are incremental. I might of course have
missed important aspects. In that case we will see that in due time and
can decide then about what to do.
> However, from reading some of your other comments we may not be very far
> apart. BRANCH_2_1_X was probably not the best name. If STABLE had been
> chosen then we could be doing what you are proposing on that branch,
> while leaving trunk open for some of the more radical changes we are doing.
>
> The real issue here is that we all know we need to get to the "real
> block" architecture, but we simply have not been able to make it happen
> for the last 2 years.
Exactly, and I believe that this in part depends on the idea that
radical change is needed. I have seen very few examples on when "next
generation" projects actually have succeded and numerous when they
haven't. So I'm rather suspicious about all plans that requires radical
change. To me it sounds like a recepie for dissaster and that one
haven't thought enough about how to get from here to there.
>> If we, after having voted about it, introduce back incompability, it
>> means that the next release should go from 2.1.x to 2.2.0 e.g. It
>> shouldn't be a greater deal than so. We can also step up the version
>> because we feel that we want to marketing some important addition.
>>
>> We should base our releases on what we actually have done rather on
>> what we wish that someone else should develop.
>
> There is some truth to this, but we could be doing this today. All this
> means is that when we wish to deliver something that introduces an
> incompatibility we do it purposefully on the "stable" branch, and we
> change the release number accordingly. As I recall this is right in
> line with the version document we agreed upon that Carsten referenced.
Yes.
>> --- o0o ---
>>
>> For our current situation I think we could release a 2.2.0 right away.
>> It doesn't contain what we planned for but OTH it contains a lot of
>> goodies that we didin't plan for and that should be usefull for a
>> larger audience.
>
> Disagree.
> First, I want to see Cocoon Forms marked stable, even if the next
> release is 2.1.8, IMO that has got to happen.
We all want to see Cocoon Forms marked stable. But most of us, I for
example, don't do anything to make it happen.
> Second, has anybody stress
> tested trunk? Or documented what incompatibilities have been
> introduced? Or even what features it provides?
Don't know. Reinhard and maybe Sylvain at least seem to use it for
customer systems maybe there are more.
> Heck, if someone asked
> me what the benefit of the current trunk is over the 2.1.X branch I
> don't think I could tell them. I know the core has changed a lot....
This is the most popular reference:
http://www.anyware-tech.com/blogs/sylvain/archives/000171.html
> So, convince me that trunk is ready for prime time and then I'll agree.
It's not ready for prime time but it is ready for being released as
alpha. It will need some time and testing and API tidying before we can
mark it as stable.
>> When/if we finish the blocksl, or some other important stuff we can
>> release 2.3 or even 3.0 if we feel like it.
>>
>> --- o0o ---
>>
>> I haven't made much release related work in the past and its far from
>> my number one itch right now, so this take this semi rant for what it is.
>>
>> But IMO we should stop this wishfull thinking based "major next
>> version" nonsense, sooner rahter than later. And also stop difussing
>> our energy in pointless branching.
>
> In my view, the problem here is that we all want "real blocks". Not
> delivering that is extremely disappointing and frustrating. What is
> worse, whenever we do stuff to the core I don't think we are actually
> sure we are getting any closer to the goal. That's why we get excited
> when we see some new thing come along that looks like it will get us a
> significant way towards the goal.
> We actually don't do a lot of branching. In some environments a branch
> is cut for every release so that maintenance can be performed against
> previously shipped releases. Be thankful we don't do that.
I am ;)
/Daniel
Re: [RT] Releases
Posted by Ralph Goers <Ra...@dslextreme.com>.
Daniel Fagerstrom wrote:
> <snip>
>
> Since 2000 we have managed to ship a handfull of 2.0 and a handfull of
> 2.1 releases. Considering the amount of activity and the volume and
> quality of what have done during that period it must be a hard to beat
> record in conservative version numbering ;)
>
> --- o0o ---
>
> IMO we should find a less demanding and more realistic attitude for
> Cocoon releases, so that we can go towards "release early, release
> often".
More frequent releases would be a good thing.
>
> Planning what should be part of the next major release seem harmfull,
> as the relase can stall forever if there is a difference between what
> we would like to have in the release and what we actually are
> implementing.
I don't think I understand. Or maybe I do. It sounds like you just
want to do stuff and release with no community discussion over the
direction Cocoon should go. However, I agree that just discussing
endlessly is pretty useless. But planning is a good thing - even if it
just means saying "no your enhancement cannot go in the next release
because it breaks incompatibility, but it can go in the following one if
we provide warning now".
>
> --- o0o ---
>
> IMO we should *only* work at trunk. No "stable" branches, we should
> instead making sure that core functionality always is stable, and find
> incremental ways for changing core functionality.
Absolutely disagree. Stable branches are required so that you can
maintain a stable delivery at all times. 2.1 is doing very well in that
regard. I cannot see how we could move to an architecture that supports
real blocks in an incrementatl fashion while maintaining the stability
we need to provide our customers.
However, from reading some of your other comments we may not be very far
apart. BRANCH_2_1_X was probably not the best name. If STABLE had been
chosen then we could be doing what you are proposing on that branch,
while leaving trunk open for some of the more radical changes we are doing.
The real issue here is that we all know we need to get to the "real
block" architecture, but we simply have not been able to make it happen
for the last 2 years.
>
> If we, after having voted about it, introduce back incompability, it
> means that the next release should go from 2.1.x to 2.2.0 e.g. It
> shouldn't be a greater deal than so. We can also step up the version
> because we feel that we want to marketing some important addition.
>
> We should base our releases on what we actually have done rather on
> what we wish that someone else should develop.
There is some truth to this, but we could be doing this today. All this
means is that when we wish to deliver something that introduces an
incompatibility we do it purposefully on the "stable" branch, and we
change the release number accordingly. As I recall this is right in
line with the version document we agreed upon that Carsten referenced.
>
> --- o0o ---
>
> For our current situation I think we could release a 2.2.0 right away.
> It doesn't contain what we planned for but OTH it contains a lot of
> goodies that we didin't plan for and that should be usefull for a
> larger audience.
Disagree.
First, I want to see Cocoon Forms marked stable, even if the next
release is 2.1.8, IMO that has got to happen.
Second, has anybody stress tested trunk? Or documented what
incompatibilities have been introduced? Or even what features it
provides? Heck, if someone asked me what the benefit of the current
trunk is over the 2.1.X branch I don't think I could tell them. I know
the core has changed a lot....
So, convince me that trunk is ready for prime time and then I'll agree.
>
> When/if we finish the blocksl, or some other important stuff we can
> release 2.3 or even 3.0 if we feel like it.
>
> --- o0o ---
>
> I haven't made much release related work in the past and its far from
> my number one itch right now, so this take this semi rant for what it is.
>
> But IMO we should stop this wishfull thinking based "major next
> version" nonsense, sooner rahter than later. And also stop difussing
> our energy in pointless branching.
In my view, the problem here is that we all want "real blocks". Not
delivering that is extremely disappointing and frustrating. What is
worse, whenever we do stuff to the core I don't think we are actually
sure we are getting any closer to the goal. That's why we get excited
when we see some new thing come along that looks like it will get us a
significant way towards the goal.
We actually don't do a lot of branching. In some environments a branch
is cut for every release so that maintenance can be performed against
previously shipped releases. Be thankful we don't do that.
>
> We should be proud of what we *actually* achieve, and step up the
> first decimal as soon as we have added some important feature.
>
> /Daniel
Re: [RT] Releases
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>
>>Sometime ago we started on drafting a versioning policy
>>
>>http://cocoon.apache.org/versioning.html
>>
>>but that didn't find much interest :(
>
>
> hmmm, I had the impression that we agreed on this. Maybe only a vote is missing.
>
I'm note sure, but I think we even had a vote...what is missing is
"following this road".
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Releases
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Sometime ago we started on drafting a versioning policy
>
> http://cocoon.apache.org/versioning.html
>
> but that didn't find much interest :(
hmmm, I had the impression that we agreed on this. Maybe only a vote is missing.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT] Releases
Posted by Carsten Ziegeler <cz...@apache.org>.
Sometime ago we started on drafting a versioning policy
http://cocoon.apache.org/versioning.html
but that didn't find much interest :(
So, whatever we write down/decide as a policy, you need committers doing
some work and trying to push that. Projects like Eclipse have a far
better grounding as there are many people paid full time to get Eclipse
out of the door; and this of course enables the project to build a
timeline with a roadmap. And not only to create a roadmap but also to
follow it. If you're "just" volunteer based, like most os projects in
fact are, including Cocoon, this will imho never really work.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/