Re: [RT] Releases
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
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
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
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 [EMAIL PROTECTED] 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
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
[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
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, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Releases
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
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
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, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Releases
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
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
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
Re: [RT] Releases
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
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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Releases
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