Re: Release roadmap
Carsten Ziegeler wrote: Reinhard Poetz wrote: Joerg Heinicke wrote: IMHO this is too fast. We did not receive any feedback on the 2.2 stuff from any non-committer (only people working with committers). We should run through some release candidates first, which gives the users the impression of having something at least testable. If we want to push the final 2.2 release now and if the current trunk is feature complete, we should do a RC 1 release (not another milestone) and see how it is accepted. With M2 soon and final release only one month later I feel like flying blind ... +1. let's have some more milestone releases and release candiates before we make the first official release because all contracts that we establish with an official release _are_ carved in stone. And as we know it takes a long time to get rid of badly designed/implemented things again. Yes, of course I agree with this in general, but personally I doubt that releasing a 2.2-RCx will give us more feedback (perhaps I'm too pessimistic on this). This could work if we provided binary distributions with NO need to fight maven. Then all you need to do is to create a webapp, copy cocoon jars and put own resources into appropriate classpath paths. My feeling is 2.2 is far from being stable. I am rebuilding cocoon at least once a week to get some bugs resolves/new features working. Cocoon core and deployer have changed so frequently last weeks/months that even me constantly rebuilding and updating all my projects manually lost track few times. What drives me nuts is that fact that webapps created with previous deployer versions loose compatibility with latest core). My coworkers are quite desperate about cocoon: hardly any of them understand the errors webapp spits out when a new build is introduced. On the bright side: Even thoughs some things still are a little bit shaky my every new project is using the lastest 2.2 in production and I do not notice and major failures. -- Leszek Gawron, 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: Release roadmap
On Thu, 2 Nov 2006, Leszek Gawron wrote: Date: Thu, 02 Nov 2006 22:14:32 +0100 From: Leszek Gawron [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Release roadmap Carsten Ziegeler wrote: Reinhard Poetz wrote: Joerg Heinicke wrote: IMHO this is too fast. We did not receive any feedback on the 2.2 stuff from any non-committer (only people working with committers). We should run through some release candidates first, which gives the users the impression of having something at least testable. If we want to push the final 2.2 release now and if the current trunk is feature complete, we should do a RC 1 release (not another milestone) and see how it is accepted. With M2 soon and final release only one month later I feel like flying blind ... +1. let's have some more milestone releases and release candiates before we make the first official release because all contracts that we establish with an official release _are_ carved in stone. And as we know it takes a long time to get rid of badly designed/implemented things again. Yes, of course I agree with this in general, but personally I doubt that releasing a 2.2-RCx will give us more feedback (perhaps I'm too pessimistic on this). This could work if we provided binary distributions with NO need to fight maven. Then all you need to do is to create a webapp, copy cocoon jars and put own resources into appropriate classpath paths. My feeling is 2.2 is far from being stable. I am rebuilding cocoon at least once a week to get some bugs resolves/new features working. Cocoon core and deployer have changed so frequently last weeks/months that even me constantly rebuilding and updating all my projects manually lost track few times. What drives me nuts is that fact that webapps created with previous deployer versions loose compatibility with latest core). That's the downside living at the bleeding edge :-) I've gone through it as well but several time but won't stop getting the structure refactored for simplicity upon to a final release. After than structure should not change anymore (hopefully). My coworkers are quite desperate about cocoon: hardly any of them understand the errors webapp spits out when a new build is introduced. On the bright side: Even thoughs some things still are a little bit shaky my every new project is using the lastest 2.2 in production and I do not notice and major failures. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: Release roadmap
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Joerg Heinicke wrote:
IMHO this is too fast. We did not receive any feedback on the 2.2 stuff
from any non-committer (only people working with committers). We should
run through some release candidates first, which gives the users the
impression of having something at least testable. If we want to push the
final 2.2 release now and if the current trunk is feature complete, we
should do a RC 1 release (not another milestone) and see how it is
accepted. With M2 soon and final release only one month later I feel
like flying blind ...
+1. let's have some more milestone releases and release candiates before we make
the first official release because all contracts that we establish with an
official release _are_ carved in stone. And as we know it takes a long time to
get rid of badly designed/implemented things again.
Yes, of course I agree with this in general, but personally I doubt that
releasing a 2.2-RCx will give us more feedback (perhaps I'm too
pessimistic on this).
there was at least one user who tried Cocoon 2.2 and asked questions about it on
[EMAIL PROTECTED] Generally I think that documentation will make a big difference,
but well, maybe I'm too optimistic ;-)
And to be honest, my intention of the statement to get 2.2 out this
year, was a try to push things. I guess we all remember that set up a
roadmap for 2.2 some time ago (when was it, at the ApacheCon EU?) to
release milestones of 2.2 every 4 to 6 weeks and the final version in
september/october 2006. So far we managed to release just one milestone...
yes, I know. I planned to push things more in October but some unforseeable
changes in projects forced me to change my schedule. But now, it seems that I
have more time :-)
So, agreeing with your statements from above, let's release a m2 this week.
+1, I can help with the release
(http://cocoon.zones.apache.org/daisy/documentation/g2/1199.html) if you do it
on Thursday and/or Friday. We should also use the new Cocoon staging repository.
Jorg, what's the current status of it?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Release roadmap
Ralph Goers wrote: +1. Does this avoid the problem of the Rhino license though (with 2.1)? No :( But I think (though I'm not sure) that we have one year to change something, so it should be fine to release 2.1.10 as is. But obviously if we don't change 2.1.x, we won't be able to release something from that branch next year. Carsten Carsten Ziegeler wrote: Our last official release has happened a long time ago... I think it's time to release something again :) Imho we should release 2.2-M2 asap and 2.1.10 as well. I think 2.1.10-dev is currently working pretty fine and there shouldn't be any outstanding issues. Or did I oversee something? The release of 2.1.10 should be the last planned release for 2.1.x - we should drop the block sharing between trunk and the branch of the blocks right after the release and continue development of things only in trunk from that point on. Only bug fixes should go to 2.1.x from that point on. This will ensure that we have to work on trunk to get a new feature release out and will stop people from adding everything to 2.1.x (hopefully). So my idea is to release 2.1.10 in the midth of November and do at the same time (or even before) a release of 2.2-m2. We can then target the final release of 2.2 for December. WE SHOULD REALLY GET 2.2 OUT *THIS YEAR*. If some parts of the new blocks stuff are not working at that time it is not that important. We can easily fix this with a 2.2.1 release or (2.3). Although I totally agree that documentation for 2.2 is really really important, let's not see this as a blocker. Either people will document stuff or not, but we will not enforce this by blocking the release. I'll work on the docs for the new core stuff next week and add the missing pieces. So, WDYAT? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Release roadmap
Nathaniel Alfred wrote: +1 to release 2.2-M2 +1 to release 2.1.10 +1 to drop block sharing -1 to put 2.1.x into *pure* bug fixing mode We should try to attract people to 2.2 rather than pushing them away from 2.1 (because they may go somewhere else). Agreed. SNIP/ So my proposal is simply use a different wording and to declare 2.1.x to be in maintenance mode. Only bug fixing *and minor enhancements* will be applied and we continue to make 1-2 releases/year. Fair enough - in the end we can't enforce people to commit just bug fixes anyway. And there is always a thin line between a bug fix, a minor enhancement, a not-minor-anymore enhancement and so on. I totally agree with your wording - it's far better! Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Release roadmap
Joerg Heinicke wrote: On 27.10.2006 20:57, Carsten Ziegeler wrote: We can then target the final release of 2.2 for December. WE SHOULD REALLY GET 2.2 OUT *THIS YEAR*. IMHO this is too fast. We did not receive any feedback on the 2.2 stuff from any non-committer (only people working with committers). We should run through some release candidates first, which gives the users the impression of having something at least testable. If we want to push the final 2.2 release now and if the current trunk is feature complete, we should do a RC 1 release (not another milestone) and see how it is accepted. With M2 soon and final release only one month later I feel like flying blind... +1. I understand people's desire to have 2.2 out (finally!) but the final user testing phase should not be neglected. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Release roadmap
Joerg Heinicke wrote:
On 27.10.2006 20:57, Carsten Ziegeler wrote:
The release of 2.1.10 should be the last planned release for 2.1.x - we
should drop the block sharing between trunk and the branch of the blocks
right after the release and continue development of things only in trunk
from that point on.
+1
So my idea is to release 2.1.10 in the midth of November and do at the
same time (or even before) a release of 2.2-m2.
+1
We can then target the final release of 2.2 for December.
WE SHOULD REALLY GET 2.2 OUT *THIS YEAR*.
IMHO this is too fast. We did not receive any feedback on the 2.2 stuff
from any non-committer (only people working with committers). We should
run through some release candidates first, which gives the users the
impression of having something at least testable. If we want to push the
final 2.2 release now and if the current trunk is feature complete, we
should do a RC 1 release (not another milestone) and see how it is
accepted. With M2 soon and final release only one month later I feel
like flying blind ...
+1. let's have some more milestone releases and release candiates before we make
the first official release because all contracts that we establish with an
official release _are_ carved in stone. And as we know it takes a long time to
get rid of badly designed/implemented things again.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Release roadmap
Reinhard Poetz wrote: Joerg Heinicke wrote: IMHO this is too fast. We did not receive any feedback on the 2.2 stuff from any non-committer (only people working with committers). We should run through some release candidates first, which gives the users the impression of having something at least testable. If we want to push the final 2.2 release now and if the current trunk is feature complete, we should do a RC 1 release (not another milestone) and see how it is accepted. With M2 soon and final release only one month later I feel like flying blind ... +1. let's have some more milestone releases and release candiates before we make the first official release because all contracts that we establish with an official release _are_ carved in stone. And as we know it takes a long time to get rid of badly designed/implemented things again. Yes, of course I agree with this in general, but personally I doubt that releasing a 2.2-RCx will give us more feedback (perhaps I'm too pessimistic on this). And to be honest, my intention of the statement to get 2.2 out this year, was a try to push things. I guess we all remember that set up a roadmap for 2.2 some time ago (when was it, at the ApacheCon EU?) to release milestones of 2.2 every 4 to 6 weeks and the final version in september/october 2006. So far we managed to release just one milestone... So, agreeing with your statements from above, let's release a m2 this week. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Release roadmap
Has someone attended to the remaining licensing issues? I managed to update all the headers in source files and will do so again just before the releases. However, that is all that i can do. The remaining tasks were noted in some past emails. Going by memory they were: NOTICE.txt and LICENSE.txt files; Check the licenses for third-party products; Somehow refer to such products from LICENSE.txt -David
Re: Release roadmap
+1. Does this avoid the problem of the Rhino license though (with 2.1)? Carsten Ziegeler wrote: Our last official release has happened a long time ago... I think it's time to release something again :) Imho we should release 2.2-M2 asap and 2.1.10 as well. I think 2.1.10-dev is currently working pretty fine and there shouldn't be any outstanding issues. Or did I oversee something? The release of 2.1.10 should be the last planned release for 2.1.x - we should drop the block sharing between trunk and the branch of the blocks right after the release and continue development of things only in trunk from that point on. Only bug fixes should go to 2.1.x from that point on. This will ensure that we have to work on trunk to get a new feature release out and will stop people from adding everything to 2.1.x (hopefully). So my idea is to release 2.1.10 in the midth of November and do at the same time (or even before) a release of 2.2-m2. We can then target the final release of 2.2 for December. WE SHOULD REALLY GET 2.2 OUT *THIS YEAR*. If some parts of the new blocks stuff are not working at that time it is not that important. We can easily fix this with a 2.2.1 release or (2.3). Although I totally agree that documentation for 2.2 is really really important, let's not see this as a blocker. Either people will document stuff or not, but we will not enforce this by blocking the release. I'll work on the docs for the new core stuff next week and add the missing pieces. So, WDYAT? Carsten
RE: Release roadmap
+1 to release 2.2-M2 +1 to release 2.1.10 +1 to drop block sharing -1 to put 2.1.x into *pure* bug fixing mode We should try to attract people to 2.2 rather than pushing them away from 2.1 (because they may go somewhere else). I expect to be stuck with 2.1.x for the next 1-2 years. That's a bit too long to be forbidden to add enhancements we might need along the way for new projects. Going to 2.2 anytime soon is unlikely for us because we just finished migrating from 2.1.m3 to 2.1.10-dev. Selling to management another migration project before 2008 would be very hard, especially since the current 2.2 has new feature really interesting to us. Also, everytime I try to dive into 2.2 I hit a brick wall of Maven magic. Cocoon documentation is important but currently even more lacking is Maven2 documentation. Carsten, Daniel, Reinhard, and few others seem to get along pretty well with M2 which gives me hope that the rest of us can follow too. But currently I have the feeling that for the majority of committers 2.2 is still uncharted territory. (Or is it only me?) So my proposal is simply use a different wording and to declare 2.1.x to be in maintenance mode. Only bug fixing *and minor enhancements* will be applied and we continue to make 1-2 releases/year. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: Release roadmap
On 28.10.2006 12:37, Nathaniel Alfred wrote: -1 to put 2.1.x into *pure* bug fixing mode Selling to management another migration project before 2008 would be very hard, especially since the current 2.2 has new feature really interesting to us. Something is wrong with that sentence I guess. I miss the logic: You can't sell another migration, because the version potentially migrated to has interesting features? So my proposal is simply use a different wording and to declare 2.1.x to be in maintenance mode. Only bug fixing *and minor enhancements* will be applied and we continue to make 1-2 releases/year. Isn't it just wording? It has always been the case that the old branch has not been closed. If there is any interest in applying an enhancement to an old branch, just do it. Nobody will prevent you from doing it. But you simply can't expect from every committer to also do the back porting. So any maintenance of the older branch is up to the individual one still having interest in it. At the end interest will simply decrease and the branch will be going to sleep - as it happened with 2.0.x. Jörg
Re: Release roadmap
On 27.10.2006 20:57, Carsten Ziegeler wrote: The release of 2.1.10 should be the last planned release for 2.1.x - we should drop the block sharing between trunk and the branch of the blocks right after the release and continue development of things only in trunk from that point on. +1 So my idea is to release 2.1.10 in the midth of November and do at the same time (or even before) a release of 2.2-m2. +1 We can then target the final release of 2.2 for December. WE SHOULD REALLY GET 2.2 OUT *THIS YEAR*. IMHO this is too fast. We did not receive any feedback on the 2.2 stuff from any non-committer (only people working with committers). We should run through some release candidates first, which gives the users the impression of having something at least testable. If we want to push the final 2.2 release now and if the current trunk is feature complete, we should do a RC 1 release (not another milestone) and see how it is accepted. With M2 soon and final release only one month later I feel like flying blind ... Jörg
Re: Release roadmap
Thanks Carsten for the roadmap: +0 to release 2.2-M2 (as I probably won't find time to help) +1 to release 2.1.10 +1 to drop block sharing And, like Alfred, I'm -1 on making 2.1.10 the last 2.1.x release I think maintenance mode is much more appropriate for 2.1.x than no more updates, I don't see a problem with releasing more 2.1.x versions (although probably much less often than 2.2 releases). As a concrete example, backporting the fop-ng block to 2.1.x is easy, doesn't impact existing code and can be useful for people still running 2.1.x. I don't see why this shouldn't happen if some people want to do it. -Bertrand
RE: Release roadmap
From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Selling to management another migration project before 2008 would be very hard, especially since the current 2.2 has new feature really interesting to us. Something is wrong with that sentence I guess. I miss the logic: You can't sell another migration, because the version potentially migrated to has interesting features? Oops, missing negation. *no* new feature really interesting to *us*. Isn't it just wording? It has always been the case that the old branch has not been closed. If there is any interest in applying an enhancement to an old branch, just do it. Nobody will prevent you from doing it. But you simply can't expect from every committer to also do the back porting. So any maintenance of the older branch is up to the individual one still having interest in it. At the end interest will simply decrease and the branch will be going to sleep - as it happened with 2.0.x. Yes, it's all about wording. Let 2.1.x go to sleep but don't kill it. Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Release roadmap
Our last official release has happened a long time ago... I think it's time to release something again :) Imho we should release 2.2-M2 asap and 2.1.10 as well. I think 2.1.10-dev is currently working pretty fine and there shouldn't be any outstanding issues. Or did I oversee something? The release of 2.1.10 should be the last planned release for 2.1.x - we should drop the block sharing between trunk and the branch of the blocks right after the release and continue development of things only in trunk from that point on. Only bug fixes should go to 2.1.x from that point on. This will ensure that we have to work on trunk to get a new feature release out and will stop people from adding everything to 2.1.x (hopefully). So my idea is to release 2.1.10 in the midth of November and do at the same time (or even before) a release of 2.2-m2. We can then target the final release of 2.2 for December. WE SHOULD REALLY GET 2.2 OUT *THIS YEAR*. If some parts of the new blocks stuff are not working at that time it is not that important. We can easily fix this with a 2.2.1 release or (2.3). Although I totally agree that documentation for 2.2 is really really important, let's not see this as a blocker. Either people will document stuff or not, but we will not enforce this by blocking the release. I'll work on the docs for the new core stuff next week and add the missing pieces. So, WDYAT? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Release roadmap
On 10/27/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: snip/ So my idea is to release 2.1.10 in the midth of November and do at the same time (or even before) a release of 2.2-m2. +1 (can I vote +2.1.10?) We can then target the final release of 2.2 for December. +1 assuming that it is ready... -- Peter Hunsberger
