On 5/25/11 4:18 PM, Jonathan M Davis wrote:
> deprecated<- deprecated, no message
> deprecated("msg")<- deprecated with a message
> deprecated("msg", hard)<- same thing
> deprecated("msg", soft)<- scheduled for deprecation with message.

I think such language changes would be beneficial.

Andrei

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

On 5/25/11 5:52 PM, Jonathan M Davis wrote:
[snip]

All sounds good to me.

Andrei

Le 2011-05-25 ? 18:52, Jonathan M Davis a ?crit :

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

Or just don't give a full date:

	"scheduled for deprecation in November 2011."

The month should be enough. There's about one release per month.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On 2011-05-25 17:16, Michel Fortin wrote:
> Le 2011-05-25 ? 18:52, Jonathan M Davis a ?crit :
> > 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.
> 
> Or just don't give a full date:
> 
> "scheduled for deprecation in November 2011."
> 
> The month should be enough. There's about one release per month.

Actually, I was just looking at the changelog to see how often releases really are and the last few have been 2 or 3 months apart whereas around a year ago, we were getting them around every month or so. So, the frequency of releases seems to have slowed down. From a planning perspective, it would be nice if we were actually consistent about it, though obviously it's best to only release when we're ready to. It might be good to specifically try for monthly or bi- monthly releases at around the same time of month each time and thus make them more consistent.

Regardless, stating a particular month seems like a good idea. It could be something like,

"As of phobos 2.054, scheduled for deprecation in November 2011"

It would clearly indicate when the change was made (without having to worry about when the exact date of 2.054) and the approximate time that the item will be deprecated. It would be easier to pick the actual deprecation month though if we were more consistent with our releases. I don't know what all goes into that though. It seems to happen primarily because someone says that they think that it's about time that we do a release, and then we do a release some time after that, though not necessarily all that quickly even then. It's worked overall, but it's not as regular or organized as might be ideal.

- Jonathan M Davis