[phobos] Decision on length of deprecation cycle

Jonathan M Davis jmdavisProg at gmx.com
Wed May 25 14:20:25 PDT 2011


On 2011-05-25 14:02, Andrei Alexandrescu wrote:
> That should work. But then why not sticking to the current intended
> scheme? Every release, whatever has aged sufficiently gets deprecated
> and then removed.

Overall, I prefer that scheme. As soon as you worry about how long has been 
scheduled for deprecated or deprecated, you have to check how much it's aged 
anyway. It is true, however, that we don't really have a good way of keeping 
track of how long something has been deprecated other than simply checking the 
last few releases after a release to see what has aged enough to move to the 
next phase for the next release. But that's not particularly hard, and it 
wouldn't be all that hard for a developer to keep track of it themself if they 
were the one who was deprecating it. If we wanted to be more organized about 
it though, we could have a file which listed what was moved to which phase 
when. Regardless, I think that it makes more sense and is more conducive to 
progress move stuff from one phase to another based on when it moved into its 
current phase rather than on a date of the year unrelated to when it was put 
on the deprecation path. The main question is how long each phase should 
typically take. If it were only two releases, then there's probably some stuff 
which is currently scheduled for deprecation which we could now deprecate. If 
it were 6 releases, then there's probably nothing which should be being 
deprecated just yet. We need to decide on at least an approximate length of 
time, since then it's better organized, and we can then give some guarantees 
to those who ask about it.

- Jonathan M Davis


More information about the phobos mailing list