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