On Thursday, 23 May 2013 at 16:19:26 UTC, Jesse Phillips wrote:
I realize this, but you are arguing by using examples of those that don't ever want to change (they do exist, and they only change because they are forced to).
I am using examples of real-world stability maniacs I have personally encountered :) Those guys (management) do want to change process though if it brings some potential profit. They will only do it in a fully controlled way though and once in a few years, thus all the hype about LTS.
There shouldn't need to bring up the works/doesn't argument because that isn't what we are after. We want to provide some category of bug fixes or library additions for a defined period of time, while elsewhere we are making language improvements, which will eventual freeze and then later replace previous release.
Well, I have been proposing something like this in one old thread I remember you posting to :)
Those who wish to never receive a non-breaking change are stuck with whatever version of the compiler they started building with. I'm not saying this to be mean, only because you can't change the compiler without the potential of having broken something somewhere (and now someone relying on that broken behavior).
That is not mean, that is reasonable. Only deal is about categorization - I argue that "backwards compatible or not" is a more useful one that "feature or bug-fix".
