On Thursday, 13 March 2014 at 08:16:50 UTC, Andrej Mitrovic wrote:
On 3/13/14, Walter Bright <newshou...@digitalmars.com> wrote:
I didn't even know about this client before the breakage.
I'm really getting tired of this argument. An unknown client
(which
you still haven't named, so as far as I'm concerned it might as
well
be just a reddit troll) comes out of the blue, complains about
some
small breakage which can *easily* be fixed in a point release,
and
suddenly that has to affect the decision on final by default.
Also,
the client hasn't bothered to file a bug report, and 2.056 has
been
released for a few weeks (nevermind the massively long beta
cycle).
Hi guys,
I happen to be one of "the clients" in case.
We have several tools and apps written in D, in production, and
we're actively trying to convert other portions of our systems
too. We're an italian company managing the technical background
of several startups (and "grown-ups") ranging from simple
editorial/publishing business to realtime restaurant reservations
and so on.
I think you can do every changes you need / you want but you
should allow some time for people to update to new versions. No
problems if you want to set a function as "deprecated" (or even a
whole library) but please don't break compatibility all of a
sudden (and without warning even in the changelog).
A breaking change drives to different problems:
- If you have code in production, code switching is a bit painful
because you have to change code all at once. A short-period
transition supported by "deprecated methods" makes it all easier
to do.
- If your deployment system is automated (code updating and
compiling) it's a bit difficult to sync the upgrade of compiler
and code. If you upgrade your compiler first, code won't compile.
If you upgrade your code first, it won't compile too. So in that
(hopefully short) range of time your deployment system is not
working.
- Changes could affect also third party libraries you're using in
production, and that's even worse. You have to wait and hope they
will fix that quickly.
- You can't always do a search/replace to fix the problems, and
it could take a long time to fix all the involved code. A
breaking change could also lead to a change of code structure.
And probably it's a good idea to do all the needed tests after
this, in order to check if the app is working as expected. In the
meanwhile you can't use the new compiler with potential
security/bug/performance fixes: you're stuck on the old version.
Thanks,
Daniele
