Final by default?

Daniele Vian dontreply at example.com
Thu Mar 13 02:21:11 PDT 2014


On Thursday, 13 March 2014 at 08:16:50 UTC, Andrej Mitrovic wrote:
> On 3/13/14, Walter Bright <newshound2 at 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



More information about the Digitalmars-d mailing list