D has become unbearable and it needs to stop
Chris Katko
ckatko at gmail.com
Fri Jun 23 19:11:39 UTC 2023
On Monday, 19 June 2023 at 17:55:40 UTC, bachmeier wrote:
> This problem has a simple solution. Fewer compiler releases.
> I'm all for bug fixes, but it has nothing to do with reducing
> the frequency of compiler releases. If bug fixes are that
> important, we'd already be doing it.
No, I don't think solution is to significantly delay features on
a rapidly developed language. Features draw new users in, and
keep people remembering and thinking about a new language. "I
wonder what cool thing I can do with this new feature"
I think a simple solution is mark all non-LTS releases as "beta",
as in "buyer beware if you use these", and have an LTS release
every 2/3/4 years. Having to update your codebase every say,
"four years", isn't the end of the world if you know it's coming.
If anyone is using the "beta"/"unstable" branch (or whatever you
want to call it), it's immediately on them "You should have
anticipated this could happen" if something breaks compatibility
as the language evolves. At least, it's in the language users
mind that it "could" happen and lessens the mental blow when it
_does_ happen. A kind of consenting to instability.
I would suggest two "branches". The latest LTS, and beta. You
want reliability plus bugfixes, use the LTS. You want new
features, use the beta. Expecting a small community to maintain
more than two versions is unrealistic, and a nightmare for
library developers.
As for removing features, I don't think that's been sufficiently
addressed. (Unless I missed the relevant discussion somehow.)
Removing features (without so much as a press release/blog post)
is a very dangerous precedent that forces users to think "Will my
next used feature be removed? Should I migrate to a new more
stable language?".
More information about the Digitalmars-d
mailing list