[phobos] Decision on length of deprecation cycle

[Jonathan M Davis]

On 2011-05-25 14:56, Andrei Alexandrescu wrote:
> On 5/25/11 4:20 PM, Jonathan M Davis wrote:
> > 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.
> 
> I thought of that for a bit and there are two things we could do:
> 
> 1. State the date of deprecation in the warning message. Instead of
> 
> "Warning: module xxx has been scheduled for deprecation."
> 
> we should say:
> 
> "Warning: since 2011-xx-xx, module xxx has been scheduled for deprecation."
> 
> 2. Then, it's difficult for a human being to set in mind dates that are
> six months ahead. That's what electronic calendars are for. So I propose
> we define a deprecation czar role who simply uses whatever electronic
> calendar (google, yahoo...) to enact deprecation. On the day of the
> deprecation, the czar simply makes the change in the repository. For
> that we need a self-organized, thorough person. That's why I recommend
> Jonathan.

That definitely sounds like a good (particularly since the people using it 
then know the date it was scheduled for deprecation was). My one concern with 
that is that the date would ideally coincide with the release date of a 
release of dmd, and it won't unless you specifically go in and edit all of 
those dates just prior to a release (doable but a bit annoying). The other 
option would be to mark it with the date that it will be move to the next 
phase (which is actually more useful for those who see the message), though it 
has pretty much the same problem only a bit worse, since you can't know the 
dmd release dates that far in advance. Regardless, it's fine with me to be in 
charge of it. At this point, I think that most of the functions which have 
been scheduled for deprecation have been done by me anyway (though Andrei has 
done that with several).

So, I'd suggest putting the date that the function will move to the next phase 
in the message instead of when it entered its current phase (or both dates), 
and we should try and adjust those dates just prior to a release so that they 
more or less coincide with actual releases. Then we can guarantee that the 
function will stay in that phase until at least that date (with the possible 
exception of moving it forward a week or so early if the date is right after a 
release). I can manage adjusting the dates and moving stuff from phase to 
phase if need be.

> > 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.
> 
> I'd say anything measured in months is reasonable. You aired some
> numbers at a point that seemed entirely fine to me.

I believe that I suggested approximately 6 months for each phase, and that 
seems like a nice, round number to me. I'd love to use shorter periods than 
that, but given how many people seem to be slow at upgrading to the latest dmd 
and Phobos, it may cause too many problems if we shorten them more than that.

- Jonathan M Davis