Release process and backwards compatibility

[Dicebot]

On Friday, 8 March 2013 at 20:33:20 UTC, Marco Leise wrote:
> I don't know much about the development process, but as you
> said some bugs may be features or vice versa. Sometimes real
> bugs are fixed and peoples' code breaks. But keeping the bug
> around isn't an option.
> The next code breakage comes from making array slices
> consistently rvalues (the slice structure itself, not the
> data). It's not a new idea, like introducing immutable, just
> wasn't correctly implemented from the start. I don't know if
> this warrants a LTS release already. The problem will be
> obvious and easy to fix by introducing a temp variable to pass
> as lvalue into functions taking slices by ref. Or changing
> those functions to auto-ref.

LTS release should be something time-based, not feature based. It 
is not that important what exactly goes there if it is guaranteed 
to have support for some long time.

Your post reminds me of another idea though - it could have been 
a good attitude to have a separate "breaking changes/fixes" block 
in change log and, probably, announce those upon merged pull 
request before release is even made. One of least pleasant 
qualities of breaking bug fixes is that they are discussed in 
github mostly and come in a form of surprise upon release.