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 shortly)... > > > > 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. Carsten
