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 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 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.
Cheers Lex
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.
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.
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, with a note at the bottom of the list to explain what the asterisk means.
Cheers, Matthew Brush
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
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
[...]
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.
Neat.
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 signal name change also bumped the API and ABI (probably correctly? plugins using the old signal won't work, but just re-compiling them won't fix it). An ABI change means that all plugins need to be re-compiled, so when approaching 1.22 release we should liase with Frank to try to get as near a simultaneous release of geany-plugins as possible so binary users are not left in the lurch without plugins for long.
[...]
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).
Agree, I wasn't meaning to suggest changing the comment.
[...]
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.
Sounds like we are approaching a plan.
Cheers Lex
Regards, Nick
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 12-03-19 05:29 PM, Lex Trotman wrote:
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.
Sounds like we are approaching a plan.
This sounds like a fine idea to me. Something like the attached patch is OK?
Cheers, Matthew Brush
On 20 March 2012 13:08, Matthew Brush mbrush@codebrainz.ca wrote:
On 12-03-19 05:29 PM, Lex Trotman wrote:
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.
Sounds like we are approaching a plan.
This sounds like a fine idea to me. Something like the attached patch is OK?
Yep, attached adds a bit to it.
Cheers Lex
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 20/03/2012 04:46, Lex Trotman wrote:
- Filetypes
- Move all named styles into color schemes and keep only mappings in the
filetypes files. Filetypes should no longer contain styling information,except `filetypes.common` which contains the default color scheme. Breakscompatibility with old filetypes files.
I think the filetypes.* files compatibility was not broken. Rather that overriding filetypes style defaults will break color schemes.
- Plugin API
- Rename signal `project_dialog_create` to `project_dialog_open` and
add new signal `project_dialog_close`. Increments plugin ABI so allplugins need re-compilation even if they don't use the signal.
If compiling doesn't catch any new errors, I don't think the ABI should have been broken. Maybe it's worth reverting the ABI break?
- User Interface
- Keybinding Ctrl-t has been re-purposed from "transpose line" to
"go to tag". Transpose line should be less used now the "move line"commands are available.
I've now committed a workaround - see the latest 2 commits. Existing users should see no change on upgrading Geany, even if they never edited any keybindings. New users get the new keybinding defaults.
Also, shouldn't the important/breaking things be in the same group at the top? Otherwise when we add the other changes they won't stand out.
On 21 March 2012 00:09, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 20/03/2012 04:46, Lex Trotman wrote:
- Filetypes
- * Move all named styles into color schemes and keep only mappings in
the
- filetypes files. Filetypes should no longer contain styling
information,
- except `filetypes.common` which contains the default color scheme.
Breaks
- compatibility with old filetypes files.
I think the filetypes.* files compatibility was not broken. Rather that overriding filetypes style defaults will break color schemes.
After yesterday's long discussion with Matthew thats how I understand it too (I think). Maybe it should say "Old user filetypes styles must be removed for new themes to work" or some such.
- Plugin API
- * Rename signal `project_dialog_create` to `project_dialog_open` and
- add new signal `project_dialog_close`. Increments plugin ABI so all
- plugins need re-compilation even if they don't use the signal.
If compiling doesn't catch any new errors, I don't think the ABI should have been broken. Maybe it's worth reverting the ABI break?
*Technically* is not an ABI change.
Problem is there is no way of indicating that plugins need to be updated for a perticular version of Geany, the plugins listening on the old signal will at best just not work, at worst crash when the signal never comes but subsequent ones do.
The current API test assumes that all APIs newer than that requested by a plugin will work. In situations like this Geany needs to reject plugins that ask for an API older than the breaking change because they might not work. In lieu of such a capability an ABI break is the only way we have of indicating that plugins need updating, for binary users they just update GP and they are fine (assuming the plugins using the signal are fixed before release). For users who compile GP we should add a note about updating as well as compiling, eg add to the end of this comment "Plugins using the old signal will not work and need updating from GP prior to re-compilation"
- User Interface
- * Keybinding Ctrl-t has been re-purposed from "transpose line" to
- "go to tag". Transpose line should be less used now the "move
line"
- commands are available.
I've now committed a workaround - see the latest 2 commits. Existing users should see no change on upgrading Geany, even if they never edited any keybindings. New users get the new keybinding defaults.
Looks good, suggest we add to the end of this comment "Geany will not change the binding if running with an existing configuration, only when a new configuration is created"
Also, shouldn't the important/breaking things be in the same group at the top? Otherwise when we add the other changes they won't stand out.
I thought reading Colombans post that this was the list being gathered at the top, maybe it needs a heading?
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 12-03-20 06:09 AM, Nick Treleaven wrote:
On 20/03/2012 04:46, Lex Trotman wrote:
- Filetypes
- Move all named styles into color schemes and keep only mappings in
the
- filetypes files. Filetypes should no longer contain styling
information,
- except `filetypes.common` which contains the default color scheme.
Breaks
- compatibility with old filetypes files.
I think the filetypes.* files compatibility was not broken. Rather that overriding filetypes style defaults will break color schemes.
It's true that it's not broken, it's just that a number of users will open their freshly installed Geany version and notice that they have no Scintilla styling at all, that the default color schemes don't work, and/or their own/geany-themes color schemes don't work, or some combination of those.
I actually was meaning to bring this up, and I think it was discussed in passing on IRC since I've made a branch on geany-themes to implement it. What if the color schemes and filetypes.* files had a version key in them that Geany could check and warn about such potential problems?
I was thinking the key could be something to the effect of `geany_version=1.22` in the `[theme_info]` and (a new) `[ft_info]` groups, which would be the recommended minimum version of Geany that will work properly with the file. If the key is missing (ie. existing files) or the Geany version is too low, it would prompt a simple message dialog explaining the problem, with the option to not show it again.
Does this sound workable at all?
[...]
Also, shouldn't the important/breaking things be in the same group at the top? Otherwise when we add the other changes they won't stand out.
It's fine with me, I was just following the existing format of the file and didn't fully understand what was meant about them being at the top of the file.
Cheers, Matthew Brush
On 12-03-20 06:06 PM, Matthew Brush wrote:
[...]
I actually was meaning to bring this up, and I think it was discussed in passing on IRC since I've made a branch on geany-themes to implement it. What if the color schemes and filetypes.* files had a version key in them that Geany could check and warn about such potential problems?
I was thinking the key could be something to the effect of `geany_version=1.22` in the `[theme_info]` and (a new) `[ft_info]` groups, which would be the recommended minimum version of Geany that will work properly with the file. If the key is missing (ie. existing files) or the Geany version is too low, it would prompt a simple message dialog explaining the problem, with the option to not show it again.
Does this sound workable at all?
Heh, I just found a Gist I had previously made as a demo/idea for this:
https://gist.github.com/2016617
Cheers, Matthew Brush
Le 19/03/2012 01:20, Lex Trotman a écrit :
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 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 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.
I don't see what we did that would've been backward-incompatible that wasn't already listed (keybinding change, themes, plugin ABI), but maybe I also miss some... I'll try to think a bit more if I can recall anything.
About how we should practically keep track of such changes, I suggest to simply populate NEWS when introducing such a change (or when figuring out it was such a change for the mentioned cases).
Cheers, Colomban
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel