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 _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
