On Wednesday, April 18, 2018 11:23:49 Mike Franklin via Digitalmars-d wrote: > On Monday, 2 April 2018 at 07:05:45 UTC, Mike Parker wrote: > > DIP 1013 is titled "The Deprecation Process". > > > > https://github.com/dlang/DIPs/blob/d8f6bfa1810c9774bd7d3b3dc6a7a6776ed5e > > 17e/DIPs/DIP1013.md > I've been thinking about the deprecation schedule being measure > in terms of releases, and I don't like it. How was the 10-version > schedule determined anyway; probably because it equated to 2 > years under the current release schedule (1 year as a deprecation > warning, 1 year as an error). So time is the intrinsic impetus. > If we were to move to a schedule of releases every 6 months, > would that require a deprecation period of 5 years? I sure hope > not. Or, if we were to move to a schedule of releases every > month, would the deprecation period be only 10 months? Cool! > > I suggest making it "a minimum of 2 years and a maximum of 10 > releases", or something of that nature.
I'd be totally fine with something in there indicating that the goal was to have a symbol deprecated and documented for approximately one year and deprecated and undocumented for approximately a year and that 10 releases is the number chosen on the assumption that we have a release approximately every month with the idea that releases would occasionally be late (hence 10 instead of 12). I certainly don't want the deprecation cycle to change much time-wise. Whatever the release schedule is, the deprecation schedule should be approximately two years long. In many ways I much prefer the time-based deprecations, because it's easier to manage and know when in time a deprecated symbol is going away, but based on a recent discussion on that, most everyone else involved preferred release-based deprecations - hence why this DIP uses releases. Regardless, if the consistency or frequency of our releases changes, then the number of releases to have something deprecated is definitely going to need to change. We arrived at the current two year deprecation cycle after a lot of discussions and adjustments to it in the past, and I don't see a good reason to change it now. It balances keeping symbols around long enough to give everyone plenty of time to update and actually getting rid of symbols when appropriate, instead of leaving them around permanently as cruft. Reducing the length will cause problems for those who don't update frequently, and increasing it will just make it harder to improve Phobos and would allow symbols that we want to get rid of to cause us problems for longer. On a side note, I would _really_ hate to see us go to a six month release as has occasionally been discussed. As someone who occasionally commits new functionality and fixes to Phobos, I'd very much like to have access to those commits in a reasonable timeframe instead of waiting half a year for them. - Jonathan M Davis
