On Thu, Aug 21, 2008 at 9:42 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > > On Thu, Aug 21, 2008 at 9:11 AM, Simon Laws <[EMAIL PROTECTED]>wrote: > >> >> >> On Thu, Aug 21, 2008 at 8:52 AM, haleh mahbod <[EMAIL PROTECTED]> wrote: >> >>> Doesn't deprecation mean the code will be there for a while and therefore >>> the new code will not break existing user code? >>> >>> How long will deprecated code stay around in Tuscany? It would be good to >>> establish a guideline so users can plan to move to the new code. >>> >>> Can there be a log of deprecated APIs under documentation page or >>> download page? This will help users to better plan for moving code to the >>> new APIs/SPIs. >>> >> >> >>> >>> >> >> snip... >> >> How about... >> >> deprecated = the feature will remain in the code base for at least the >> next 2 releases at the 1.X level. During this time it won't be maintained >> and users are encouraged to move away from it. After this time it is a >> candidate for removal. >> >> Thoughts? >> >> Simon >> >> >> > I think its likely to depend on the circumstances and could be different > for different types of changes. Its possible it could be fine in some > circumstances to remove a deprecated feature after just one release, for > some of the less important functions it may even be reasonable to remove > function without deprecation and just document the change in the release > notes. It is also to some degree time dependent as well as release dependent > and if we get several releases out over few months it could be better to not > remove a deprecated feature just because the set number of releases has > past. What i think is important is to consider the impact to users of > changes, so when it does seem like there could be significant user impact > then be more conservative, and vice versa. > I agree that it's a matter of circumstance but we should set some expectation. Having a variable approach will be hard to follow. I don't really object to keeping deprecated interfaces in the code base longer than we expected to keep them. Removing interfaces or changing the semantics with little warning will, I think, cause problems though. > > > As it could be hard to come up with a firm policy or guideline how about > saying changes that seem like they might impact backward compatibility > require at least lazy consensus, so post to the ML and wait at least 72 > hours before making the change? > So this is a different but very good question. How do we judge whether a change is likely to affect backward compatibility? We have to look for red flags such as; does the change require changes to unit tests, itests or samples?. Given that we have some warning that a change is planned we can decide the best approach re. deprecation and migration. > > ..ant > >
