You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/04/11 22:13:06 UTC
[proposal] rethinking distribution strategy
Let's face it: we suck at releasing early and often.
We are plagued by the fear of breaking contracts, so we release only
when we are absolutely positive those contracts won't break. Which
normally means "never".
So, the result is that we don't acquire the user feedback that allows us
to shake those contracts and see how solid they are.
Result: stall.
- o -
I propose the following:
1) release Cocoon 2.1 beta *RIGHT NOW*. This means package what we have
and shipt it. No cleanup, no todo list, no docs to add, nothing. Just
"build dist" and go go go.
2) change the meaning of "beta" from "API solid, code somewhat shaky"
to "code solid, API somewhat shaky".
What does it mean for users:
a) they get a release we consider stable in code (in fact cocoon
2.1-dev is pretty damn rock solid from a code point of view, I never had
a failure in months and many are using it in production with no problems)
b) they get to try out the new features and get their hands dirty, but
we warn them that they might require some finetuning. This shouldn't be
a big problem since it will take months for them to base anything on
production on the new features and by then we'll have released the final
version.
What does it mean for developers:
a) we finally get this thing out of the door and feel releaved.
b) user feedback will help us polish our contracts much more than we
can do ourselves talking between us only
c) the stall is broken
What do you think?
--
Stefano.
Re: [proposal] rethinking distribution strategy
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 11 Apr 2003, Stefano Mazzocchi wrote:
> Let's face it: we suck at releasing early and often.
Absolutely.
> We are plagued by the fear of breaking contracts, so we release only
> when we are absolutely positive those contracts won't break. Which
> normally means "never".
>
> So, the result is that we don't acquire the user feedback that allows us
> to shake those contracts and see how solid they are.
>
> Result: stall.
>
> - o -
>
> I propose the following:
>
> 1) release Cocoon 2.1 beta *RIGHT NOW*. This means package what we have
> and shipt it. No cleanup, no todo list, no docs to add, nothing. Just
> "build dist" and go go go.
+1
> 2) change the meaning of "beta" from "API solid, code somewhat shaky"
> to "code solid, API somewhat shaky".
>
> What does it mean for users:
>
> a) they get a release we consider stable in code (in fact cocoon
> 2.1-dev is pretty damn rock solid from a code point of view, I never had
> a failure in months and many are using it in production with no problems)
I can confirm that, too. We use CVS 2.1 versions in production environment and
never had one single failure since.
The only thing that is not working from time to time are some cocoon samples
which gives the wrong impression (have a look at lenya, they suffer from the
same case).
> b) they get to try out the new features and get their hands dirty, but
> we warn them that they might require some finetuning. This shouldn't be
> a big problem since it will take months for them to base anything on
> production on the new features and by then we'll have released the final
> version.
+1
> What does it mean for developers:
>
> a) we finally get this thing out of the door and feel releaved.
Yea, finally.
> b) user feedback will help us polish our contracts much more than we
> can do ourselves talking between us only
+1
> c) the stall is broken
And this is the important issue. After that we will sure do releases every other
week ;-)
Giacomo
Re: [proposal] rethinking distribution strategy
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
> 1) release Cocoon 2.1 beta *RIGHT NOW*. This means package what we have
> and shipt it. No cleanup, no todo list, no docs to add, nothing. Just
> "build dist" and go go go.
*Big* +1, we need that.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
Re: [proposal] rethinking distribution strategy
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/12/03 4:36 PM Jeff Turner wrote:
> On Fri, Apr 11, 2003 at 10:13:06PM +0200, Stefano Mazzocchi wrote:
> ....
>
>>I propose the following:
>>
>> 1) release Cocoon 2.1 beta *RIGHT NOW*.
>
>
> How about "beta 1", to establish the notion that there could be quite a
> few of these things before 2.1 final?
Yes, that was implied in my thinking but no stated. Yes, that would be
cocoon 2.1 beta 1
> +1 to the general idea. I'm sure many projects, like Forrest and Lenya,
> have internally standardized on a certain snapshot that meet their
> criteria for stability. This formalizes that practice.
exactly. at least they will have a way to say which version they are
based on.
> When you say "code solid, API somewhat shaky", does the sitemap syntax
> fall under API? I think it might be a good idea.
Again, sorry, I wrote 'API' meaning "contracts". Yes, sitemap, flow and
all that follows into the same category.
--
Stefano.
Re: [proposal] rethinking distribution strategy
Posted by Jeff Turner <je...@apache.org>.
On Sat, Apr 12, 2003 at 07:02:26PM +0200, Stefano Mazzocchi wrote:
> on 4/12/03 5:35 PM Jeff Turner wrote:
...
> > I'm asking: should we change the namespace (implying syntax
> > stability), or keep the "...sitemap/1.0" namespace, and reserve
> > "...sitemap/2.0" for a genuinely stable 2.1-final release? I'd vote
> > for the latter as a more conservative approach that doesn't risk
> > "polluting" /2.0, like what happened to /1.0.
>
> I don't understand your proposal, please be more precise.
Just confusion about whether the sitemap syntax is regarded as stable.
Resolved by:
>> Again, sorry, I wrote 'API' meaning "contracts". Yes, sitemap, flow and
>> all that follows into the same category.
--Jeff
Re: [proposal] rethinking distribution strategy
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/12/03 5:35 PM Jeff Turner wrote:
> On Sat, Apr 12, 2003 at 04:48:03PM +0200, Giacomo Pati wrote:
>
>>On Sun, 13 Apr 2003, Jeff Turner wrote:
>>
>>
>>>On Fri, Apr 11, 2003 at 10:13:06PM +0200, Stefano Mazzocchi wrote:
>>>...
>>>
>>>>I propose the following:
>>>>
>>>> 1) release Cocoon 2.1 beta *RIGHT NOW*.
>>>
>>>How about "beta 1", to establish the notion that there could be quite a
>>>few of these things before 2.1 final?
>>
>>There are many ways to go. Many OSS projects use the "Release Candidate" term
>>for the one after the beta (i.e. Axis).
>>
>>
>>>+1 to the general idea. I'm sure many projects, like Forrest and Lenya,
>>>have internally standardized on a certain snapshot that meet their
>>>criteria for stability. This formalizes that practice.
>>>
>>>When you say "code solid, API somewhat shaky", does the sitemap syntax
>>>fall under API? I think it might be a good idea.
>>
>>Well, I don't think we have alot of shaky APIs. Most part of them are solid and
>>stabilized, isn't it?
>
>
> The sitemap syntax changed in backwards-incompatible ways between 2.0 and
> 2.1 (for example, map:pipelines -> map:pipes).
No, map:pipelines was introduced in 2.1-dev and the WARNING.txt stated
clearly that we were not considering those new things to be solid.
> Right now, a sitemap with
> the namespace "http://apache.org/cocoon/sitemap/1.0" could be for 2.0, or
> 2.1 (CVS); there's no way to tell. I gather the plan was to change the
> namespace (to "http://apache.org/cocoon/sitemap/2.0" I suppose) at the
> first beta. I'm asking: should we change the namespace (implying syntax
> stability), or keep the "...sitemap/1.0" namespace, and reserve
> "...sitemap/2.0" for a genuinely stable 2.1-final release? I'd vote for
> the latter as a more conservative approach that doesn't risk "polluting"
> /2.0, like what happened to /1.0.
I don't understand your proposal, please be more precise.
--
Stefano.
Re: [proposal] rethinking distribution strategy
Posted by Jeff Turner <je...@apache.org>.
On Sat, Apr 12, 2003 at 04:48:03PM +0200, Giacomo Pati wrote:
> On Sun, 13 Apr 2003, Jeff Turner wrote:
>
> > On Fri, Apr 11, 2003 at 10:13:06PM +0200, Stefano Mazzocchi wrote:
> > ...
> > > I propose the following:
> > >
> > > 1) release Cocoon 2.1 beta *RIGHT NOW*.
> >
> > How about "beta 1", to establish the notion that there could be quite a
> > few of these things before 2.1 final?
>
> There are many ways to go. Many OSS projects use the "Release Candidate" term
> for the one after the beta (i.e. Axis).
>
> > +1 to the general idea. I'm sure many projects, like Forrest and Lenya,
> > have internally standardized on a certain snapshot that meet their
> > criteria for stability. This formalizes that practice.
> >
> > When you say "code solid, API somewhat shaky", does the sitemap syntax
> > fall under API? I think it might be a good idea.
>
> Well, I don't think we have alot of shaky APIs. Most part of them are solid and
> stabilized, isn't it?
The sitemap syntax changed in backwards-incompatible ways between 2.0 and
2.1 (for example, map:pipelines -> map:pipes). Right now, a sitemap with
the namespace "http://apache.org/cocoon/sitemap/1.0" could be for 2.0, or
2.1 (CVS); there's no way to tell. I gather the plan was to change the
namespace (to "http://apache.org/cocoon/sitemap/2.0" I suppose) at the
first beta. I'm asking: should we change the namespace (implying syntax
stability), or keep the "...sitemap/1.0" namespace, and reserve
"...sitemap/2.0" for a genuinely stable 2.1-final release? I'd vote for
the latter as a more conservative approach that doesn't risk "polluting"
/2.0, like what happened to /1.0.
--Jeff
> Giacomo
Re: [proposal] rethinking distribution strategy
Posted by Giacomo Pati <gi...@apache.org>.
On Sun, 13 Apr 2003, Jeff Turner wrote:
> On Fri, Apr 11, 2003 at 10:13:06PM +0200, Stefano Mazzocchi wrote:
> ...
> > I propose the following:
> >
> > 1) release Cocoon 2.1 beta *RIGHT NOW*.
>
> How about "beta 1", to establish the notion that there could be quite a
> few of these things before 2.1 final?
There are many ways to go. Many OSS projects use the "Release Candidate" term
for the one after the beta (i.e. Axis).
> +1 to the general idea. I'm sure many projects, like Forrest and Lenya,
> have internally standardized on a certain snapshot that meet their
> criteria for stability. This formalizes that practice.
>
> When you say "code solid, API somewhat shaky", does the sitemap syntax
> fall under API? I think it might be a good idea.
Well, I don't think we have alot of shaky APIs. Most part of them are solid and
stabilized, isn't it?
Giacomo
Re: [proposal] rethinking distribution strategy
Posted by Jeff Turner <je...@apache.org>.
On Fri, Apr 11, 2003 at 10:13:06PM +0200, Stefano Mazzocchi wrote:
...
> I propose the following:
>
> 1) release Cocoon 2.1 beta *RIGHT NOW*.
How about "beta 1", to establish the notion that there could be quite a
few of these things before 2.1 final?
+1 to the general idea. I'm sure many projects, like Forrest and Lenya,
have internally standardized on a certain snapshot that meet their
criteria for stability. This formalizes that practice.
When you say "code solid, API somewhat shaky", does the sitemap syntax
fall under API? I think it might be a good idea.
--Jeff
> --
> Stefano.
>
>
>
Re: [proposal] rethinking distribution strategy
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Stefano Mazzocchi dijo:
> a) they get a release we consider stable in code (in fact cocoon
> 2.1-dev is pretty damn rock solid from a code point of view, I never had
> a failure in months and many are using it in production with no
> problems)
>
> What do you think?
I think there are just one important point to note. Under Sun Java
1.4.1_01, Tomcat 4.1.24 and Red Hat 8.0 the curent release has:
Restart means kill the process, the simple "./shutdown.sh" command does
not work anymore since 1 or 2 months ago. The Tomcat process remains there
remain because of Cocoon. Please note that if you dont use Cocoon. Tomcat
shutdown properly.
This issue is too problematic for a "beta" release. I can agree with an
alpha release. I know I am not a developer but I can consider my self a
tester because I am always aware of the lastest released code and compile
try it. I do that almost every day when a new change is published. A main
target is to see again Cocoon shuting down properly under the refered
environment.
Please take this message in the correct good sense. :-)
Best Regards,
Antonio Gallardo.
Re: [proposal] rethinking distribution strategy
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Stefano Mazzocchi dijo:
> on 4/12/03 5:03 PM Geoff Howard wrote:
>
>
>> I'd be for it - but what about bugs marked blocking 2.1 release? And
>> what about pending major changes to central contracts (flow)?
>> How do we avoid getting stalled in beta?
>
> by releasing early and often, fixing one issue at a time :-)
I sounds nice. Because the current experience is that the lifetime of
bugzilla issues is long. Please again take this as a critic in the totally
good sense.
Antonio Gallardo
Re: [proposal] rethinking distribution strategy
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/14/03 9:14 AM Niclas Hedhman wrote:
> On Sunday 13 April 2003 01:00, Stefano Mazzocchi wrote:
>
>>on 4/12/03 5:03 PM Geoff Howard wrote:
>>
>>>I'd be for it - but what about bugs marked blocking 2.1 release? And
>>>what about pending major changes to central contracts (flow)?
>>>How do we avoid getting stalled in beta?
>>
>>by releasing early and often, fixing one issue at a time :-)
>
>
> Additionally,
>
> The "Release Early, Release Often" seems to be inversely to the size of the
> project to be released. Initially it works well, and as the project grows,
> things are released less and less often, due to fear of "contract failures".
>
> This can easily be alleviated by breaking up the release cycles for each part,
> especially now when blocks and modules are becoming a reality.
>
> One could also require that "Core 2.n" is compatible with "Module X ver
> 2.(n-1)" and "Block Y ver 2.(n-2)", for faster and phased (not all in one
> bang) introduction of core features.
Niclas, you are always late :-)
All this is planned for Cocoon 2.2 when hotdeployable blocks will make
it possible to separate all the things we have now in /src/blocks into
separate modules with totally separate release cycles.
I expect that to make a huge change on how things move on around here.
But in order to do 2.2, we will need substantial architectural changes
and this will very likely require a new release, potentially even a 3.0
one, depending on how much the avalon contracts needs to be updated. I
still don't know.
Anyway, the build system I introduced went exactly in this direction,
but nothing more than this can be done without opening up the entire
component-loading architecture and this was even too painful to think
before a major release.
--
Stefano.
Re: [proposal] rethinking distribution strategy
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 13 April 2003 01:00, Stefano Mazzocchi wrote:
> on 4/12/03 5:03 PM Geoff Howard wrote:
> > I'd be for it - but what about bugs marked blocking 2.1 release? And
> > what about pending major changes to central contracts (flow)?
> > How do we avoid getting stalled in beta?
>
> by releasing early and often, fixing one issue at a time :-)
Additionally,
The "Release Early, Release Often" seems to be inversely to the size of the
project to be released. Initially it works well, and as the project grows,
things are released less and less often, due to fear of "contract failures".
This can easily be alleviated by breaking up the release cycles for each part,
especially now when blocks and modules are becoming a reality.
One could also require that "Core 2.n" is compatible with "Module X ver
2.(n-1)" and "Block Y ver 2.(n-2)", for faster and phased (not all in one
bang) introduction of core features.
Niclas
Re: [proposal] rethinking distribution strategy
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/12/03 5:03 PM Geoff Howard wrote:
> I'd be for it - but what about bugs marked blocking 2.1 release? And
> what about pending major changes to central contracts (flow)?
> How do we avoid getting stalled in beta?
by releasing early and often, fixing one issue at a time :-)
if not, issues pile up more quickly than we can get rid of them and
psycologically this has a devastating effect since people think release
date is never going to happen.
--
Stefano.
Re: [proposal] rethinking distribution strategy
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/14/03 11:41 AM Carsten Ziegeler wrote:
> I think, it would really help if we have more than one person that is
> able to perform all steps of a release. So, I suggest that I will do
> the next release 2.1beta1 and will then write down all the steps
> I did, so others can step in then.
I love it. +1
--
Stefano.
Re: [proposal] rethinking distribution strategy
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
<snip/>
>I think, it would really help if we have more than one person that is
>able to perform all steps of a release. So, I suggest that I will do
>the next release 2.1beta1 and will then write down all the steps
>I did, so others can step in then.
>
>Carsten
>
>
+1 for 2.1beta and +1 for some written release instructions !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [proposal] rethinking distribution strategy
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> <REARRANGED CONTENT>
> > +1 for releasing 2.1 beta 1 asap.
> >
>
> > It's a good idea to get the beta out of the door right now
> > even if something is not finished yet, but I want to remind
> > that if we have severe bugs/problems in a released beta,
> > this will not help cocoon to enter "new homes".
>
> I have the impression that this is a catch22 situation: we know there
> are bugs, but nobody really cares if not from an elegance POV.
>
> if you get the bugs out, people will start be *bugged* by them (that's
> what a bug does: bugs!) and will hopefully help us patch them or, at
> least, put enough pressure on those to blame to fix them.
>
Good point!
> > There is only one minor problem: I don't have time to prepare
> > the release right now due to some work load and the easter
> > holidays :)
> > Is the above proposed release date ok for everyone?
>
> No probs, but maybe you could post the detailed instructions on how to
> do it so others might just in and help :-)
> I think it would be much more scalable for everyone here if the release
> manager was not a single person but a process that any committer knows
> how to follow. That will also help increase the frequency since that
> removes the pressure from you.
>
> What do others think?
>
I think, it would really help if we have more than one person that is
able to perform all steps of a release. So, I suggest that I will do
the next release 2.1beta1 and will then write down all the steps
I did, so others can step in then.
Carsten
Re: [proposal] rethinking distribution strategy
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/14/03 8:15 AM Carsten Ziegeler wrote:
> +1 for releasing 2.1 beta 1 asap.
>
> There is only one minor problem: I don't have time to prepare
> the release right now due to some work load and the easter
> holidays :)
No probs, but maybe you could post the detailed instructions on how to
do it so others might just in and help :-)
> So, I could release on the 28th or 29th of april - from that
> date on it should be possible for me to do a release every
> week if required, so we will not get a delay in releasing
> any following version.
A release every one/two weeks seems perfect IMO. A very nice balance
between consistency and evolution.
> It's a good idea to get the beta out of the door right now
> even if something is not finished yet, but I want to remind
> that if we have severe bugs/problems in a released beta,
> this will not help cocoon to enter "new homes".
I have the impression that this is a catch22 situation: we know there
are bugs, but nobody really cares if not from an elegance POV.
if you get the bugs out, people will start be *bugged* by them (that's
what a bug does: bugs!) and will hopefully help us patch them or, at
least, put enough pressure on those to blame to fix them.
I really think we should stop behaving like a commercial software house:
all software has bugs and there is no way out.
what you can change is the perception of your managers and this is much
easier to do than it seems: just change "alpha" to "final" without
changing anything else.
I've done it several times for Cocoon 1.x and nobody ever noticed :-)
> Is the above proposed release date ok for everyone?
I think it would be much more scalable for everyone here if the release
manager was not a single person but a process that any committer knows
how to follow. That will also help increase the frequency since that
removes the pressure from you.
What do others think?
--
Stefano.
RE: [proposal] rethinking distribution strategy
Posted by Geoff Howard <co...@leverageweb.com>.
I'd be for it - but what about bugs marked blocking 2.1 release? And
what about pending major changes to central contracts (flow)?
How do we avoid getting stalled in beta?
Geoff
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
<snip/>
> I propose the following:
>
> 1) release Cocoon 2.1 beta *RIGHT NOW*. This means package what we have
> and shipt it. No cleanup, no todo list, no docs to add, nothing. Just
> "build dist" and go go go.
<snip/>
>
> What do you think?
>
Re: [proposal] rethinking distribution strategy
Posted by Stephan Michels <st...@apache.org>.
On Fri, 11 Apr 2003, Stefano Mazzocchi wrote:
> Let's face it: we suck at releasing early and often.
>
> We are plagued by the fear of breaking contracts, so we release only
> when we are absolutely positive those contracts won't break. Which
> normally means "never".
>
> So, the result is that we don't acquire the user feedback that allows us
> to shake those contracts and see how solid they are.
>
> Result: stall.
>
> - o -
>
> I propose the following:
>
> 1) release Cocoon 2.1 beta *RIGHT NOW*. This means package what we have
> and shipt it. No cleanup, no todo list, no docs to add, nothing. Just
> "build dist" and go go go.
>
> 2) change the meaning of "beta" from "API solid, code somewhat shaky"
> to "code solid, API somewhat shaky".
>
> What does it mean for users:
>
> a) they get a release we consider stable in code (in fact cocoon
> 2.1-dev is pretty damn rock solid from a code point of view, I never had
> a failure in months and many are using it in production with no problems)
>
> b) they get to try out the new features and get their hands dirty, but
> we warn them that they might require some finetuning. This shouldn't be
> a big problem since it will take months for them to base anything on
> production on the new features and by then we'll have released the final
> version.
>
> What does it mean for developers:
>
> a) we finally get this thing out of the door and feel releaved.
>
> b) user feedback will help us polish our contracts much more than we
> can do ourselves talking between us only
>
> c) the stall is broken
>
> What do you think?
release Cocoon 2.1 beta *RIGHT NOW*
+1 for me. At the moment I'm sick from gump. This night the gump build
break again as I tought that I have fixed the classpath problem.
http://cvs.apache.org/builds/gump/latest/cocoon.html
f**k !
Stephan Michels.
RE: [proposal] rethinking distribution strategy
Posted by Artur Bialecki <ar...@digitalfairway.com>.
I think releasing 2.1 beta is a good idea even though I
value "all" kinds of stability.
At least this way I can justify starting to consider
2.1 for production to the PHBs.
Telling them that I'm working on something that comes out of
CVS HEAD desn't give them the warm and fuzzy.
Artur...
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: April 11, 2003 4:13 PM
> To: Apache Cocoon
> Subject: [proposal] rethinking distribution strategy
>
>
> Let's face it: we suck at releasing early and often.
>
> We are plagued by the fear of breaking contracts, so we release only
> when we are absolutely positive those contracts won't break. Which
> normally means "never".
>
> So, the result is that we don't acquire the user feedback
> that allows us
> to shake those contracts and see how solid they are.
>
> Result: stall.
>
> - o -
>
> I propose the following:
>
> 1) release Cocoon 2.1 beta *RIGHT NOW*. This means package
> what we have
> and shipt it. No cleanup, no todo list, no docs to add, nothing. Just
> "build dist" and go go go.
>
> 2) change the meaning of "beta" from "API solid, code somewhat shaky"
> to "code solid, API somewhat shaky".
>
> What does it mean for users:
>
> a) they get a release we consider stable in code (in fact cocoon
> 2.1-dev is pretty damn rock solid from a code point of view,
> I never had
> a failure in months and many are using it in production with
> no problems)
>
> b) they get to try out the new features and get their hands
> dirty, but
> we warn them that they might require some finetuning. This
> shouldn't be
> a big problem since it will take months for them to base anything on
> production on the new features and by then we'll have
> released the final
> version.
>
> What does it mean for developers:
>
> a) we finally get this thing out of the door and feel releaved.
>
> b) user feedback will help us polish our contracts much more than we
> can do ourselves talking between us only
>
> c) the stall is broken
>
> What do you think?
>
> --
> Stefano.
>
>
>
RE: [proposal] rethinking distribution strategy
Posted by Stephan Michels <st...@apache.org>.
On Mon, 14 Apr 2003, Carsten Ziegeler wrote:
> +1 for releasing 2.1 beta 1 asap.
>
> There is only one minor problem: I don't have time to prepare
> the release right now due to some work load and the easter
> holidays :)
>
> So, I could release on the 28th or 29th of april - from that
> date on it should be possible for me to do a release every
> week if required, so we will not get a delay in releasing
> any following version.
>
> It's a good idea to get the beta out of the door right now
> even if something is not finished yet, but I want to remind
> that if we have severe bugs/problems in a released beta,
> this will not help cocoon to enter "new homes".
>
> Is the above proposed release date ok for everyone?
So, can we release the beta now? There are still some issues,
which must be fixed, but there will be always some bugs ;-)
Stephan.
BTW, what about a feature-freeze?
RE: [proposal] rethinking distribution strategy
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
+1 for releasing 2.1 beta 1 asap.
There is only one minor problem: I don't have time to prepare
the release right now due to some work load and the easter
holidays :)
So, I could release on the 28th or 29th of april - from that
date on it should be possible for me to do a release every
week if required, so we will not get a delay in releasing
any following version.
It's a good idea to get the beta out of the door right now
even if something is not finished yet, but I want to remind
that if we have severe bugs/problems in a released beta,
this will not help cocoon to enter "new homes".
Is the above proposed release date ok for everyone?
Greetings
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://radio.weblogs.com/0107211/