On Sunday, 2 July 2017 at 23:27:26 UTC, Seb wrote:
Proposals
---------
I think we should learn from the past. Here are a couple of
ideas:
1) Stop making such a fuzz about having a long deprecation
period. Most people will only care about a deprecation when
their project doesn't compile anymore. A deprecation period of
two releases is more than enough for users that care. As seen
even _eight_ releases don't help! (std.c was deprecated in
2.067)
The only concern I have with this is that not everyone uses DMD.
LDC typically lags the development cycle, although we try to keep
up as fast as we can.
I'm no sure about the state of GDC though. I think Iain has it up
to 2.072?
This makes it a pain for library writers who want to be
compatible with all the compilers.
2) List deprecations in the changelog -
Do we not do this already?
users who care read it (and as seen there isn't any point to
cater or wait for those who don't. I stress this point because
people notoriously don't add their breaking changes to the
changelog, which I guess has led to frustration & complains in
the past and thus resulted in the currently cautious attitude
against deprecations).
3) Ship a tool like dfmt with new releases that allows easy
upgrades to new releases
Definitely!
4) Solve the problem automatically: let a bot that crawl _all_
D source code on GH and let it submits PRs for trivial
deprecations (could be based on dfmt or other tools)
Ditto.
Especially with (3) (and optionally (4)) deprecations should
become a lot less painless and they might again gain the glance
of "awesome, we are getting rid of old, ugly stuff" instead
"please don't break anything".
[#5532]: https://github.com/dlang/phobos/pull/5532
[#2337]: https://github.com/dlang/phobos/pull/2337
[dub]: https://github.com/dlang/dub/issues/1183
[tools]: https://github.com/dlang/tools/issues/238
[vibe.d]: https://github.com/rejectedsoftware/vibe.d/issues/1811
