On 19 March 2012 12:12, Matthew Brush <mbr...@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. :)

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.

>
>
>> 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.

>
>> 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), 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.

Cheers
Lex

>
> Cheers,
> Matthew Brush
> _______________________________________________
> Geany-devel mailing list
> Geany-devel@uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Reply via email to