cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: Proposal: release management guide (was Re: [RT] Versions)
Date Fri, 23 Apr 2004 02:47:51 GMT
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.

> > 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.

> 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

--Tim Larson

View raw message