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