[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