[Geany-devel] Gathering Release 1.22 incompatibilities

[Nick Treleaven]

On 19/03/2012 01:41, Lex Trotman wrote:
> On 19 March 2012 12:12, Matthew Brush<mbrush at codebrainz.ca>  wrote:
>> On 12-03-18 05:20 PM, Lex Trotman wrote:
>>>
>>> Hi All,
>>>
>>> I recently ran into Nicks change of the default keybinding<ctrl>-t
>>> from transpose to gototag.  This made me realise we need to keep a
>>> list of incompatibilities to add to the release notes when 1.22 is
>>> released.
>>>
>>
>> I don't know if I'd consider changing a default keybinding an
>> "incompatibility" as such. IMO, unless something breaks as a result of an
>> upgrade, it's not really incompatible.
>
> Its incompatible with users fingers, and thats a *major* incompatibility. :)

Agree. I might be able to improve this a bit with a workaround, I'll 
investigate.

> Basically anything that changes the UI operation (eg moved menu items,
> keybindings, the new colourschemes dialog etc). should be mentioned so
> users are not surprised.
>
> You can get some *quite* nasty bug/ML reports if such changes are not
> brought to the users attention.  It doesn't have to be in
> incompatibilities, there can be a changed UI section as well, but I
> thought just one section would be better.

Agree, anything confusing/annoying should be clearly mentioned at the 
top of the release notes IMO.

>>> I would have thought that anything incompatible would have been
>>> forgotten by then unless we keep a running list, at the moment all I
>>> can think of is the ctrl-t and themes, but I am sure there are others.
>>>
>>
>> The only real incompatibilities I can think of are the filedefs/color
>> schemes, changes to the plugin API, and the GTK+ version bump.
>>
>
> Yeah, plugins is an important one.

I may have missed some things but offhand is this just the project 
properties signal names that got broken API-wise?

>>> The list also saves Git blaming to try to see what made the change and
>>> if it is deliberate or not.
>>>
>>> So any suggestions on how we should gather these?  and of any more of
>>> them.
>>>
>>
>> We could, at release-time, just manually scan the ChangeLog (and/or Release
>> Notes) and add an asterisk to each item that changes defaults or breaks
>> compatibility,
>
> If its obvious, but for example Nicks commit comment actually said it
> didn't affect users (not picking on Nick, that just happened to be the
> one I just fell over),

Yeah, unfortunately I forgot keybindings.conf is only saved after the 
first edit. (IIUC, commit messages shouldn't be edited after they've 
been pushed).

> so it wouldn't be obvious.  Commit comments
> often don't mention it.  So I think gathering these things as we go is
> also important.
...
> with a note at the bottom of the list to explain what the
>> asterisk means.
>
> Thats one way of presenting it yes, but I think it is best to make a
> separate list in a separate section of the release notes so it has a
> *chance* of being read by at least *some* users.  Little *s are too
> easily overlooked.

Agree, I think Colomban's idea of adding incompatible/important changes 
to the NEWS file as we go, and at the top, would work well.

Regards,
Nick