[Geany-devel] Gathering Release 1.22 incompatibilities

Lex Trotman elextr at xxxxx
Mon Mar 19 01:41:58 UTC 2012

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

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,
> Matthew Brush
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

More information about the Devel mailing list