On 19/03/2012 01:41, Lex Trotman wrote:
On 19 March 2012 12:12, Matthew Brushmbrush@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