cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: Proposal: release management guide (was Re: [RT] Versions)
Date Fri, 23 Apr 2004 08:32:50 GMT
Tim Larson wrote:
> On Thu, Apr 22, 2004 at 09:50:08PM +0200, Carsten Ziegeler wrote:
> > Tim Larson wrote: 
> > > If it happens that 2.3 comes very soon after 2.2, then the 
> > > deprecated code in effect was just deleted and not put through a 
> > > normal deprecation cycle.  Perhaps we need to also set a minimum 
> > > length of time that deprecated features will live, to ensure that 
> > > deprecation is a meaningful process and not just a formality.
> > > 
> > Hmm, yes, this is a valid point. Looking back, it always took some 
> > time between our releases, so I think we don't have to set a strict 
> > rule for this. We should just decide on a case by case base if the 
> > time inbetween releases has been long enough or if we 
> should keep the 
> > deprecated stuff in the next minor release and remove it one minor 
> > release later.
> We will need to decide on a case-by-case basis, but we should 
> also set a general guideline to help with the decisions.

Ok, we can add this when the guide is in CVS (which should be very

> > > Also, we should define what deprecation means, such as whether 
> > > simple but severe security issues will receive updates, 
> even though 
> > > more ongoing or complex updates will not happen to 
> deprecated code.
> > Can you please explain this a little bit? Do you mean, what will 
> > happen if security issues arise in deprecated code?
> Yes, that is what I am asking.  If we do not handle security 
> issues in deprecated code, our users are not in a much better 
> position than if we had just deleted the code without 
> deprecation, since they can no longer safely continue to use 
> the code in production.  If we are going to do the effort of 
> a deprecation cycle, we might as well make it mean something 
> for our users.
Ah, yes, of course. If any severe security issue arises (where 'any' means
either in deprecated or non deprecated code), we will make
a patch release. Yes.

> > Yes, agreed. And we should really start updating libaries only if 
> > there is really a good reason for it.
> For these compatible releases I agree, but I also appreciate 
> Antonio's and others' efforts in keeping these libraries up 
> to date.  I wish there were an easy way to maintain the 
> integration of both old stable and new up-to-date libraries 
> against our code.
> I admit I do not know the best, most practical, balance for 
> this issue.
Yes, in general I personally would always update to the latest
release, but for compatibility it's not always the best choice.
Now, I think Gump is doing this work for us, or? We use a
specific version and Gump builds (and tests?) Cocoon against
the latest version.


View raw message