[Geany-devel] Gathering Release 1.22 incompatibilities
nick.treleaven at xxxxx
Mon Mar 19 16:06:48 UTC 2012
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
>> 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
> 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
>> 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
> 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
> 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.
More information about the Devel