On 01/09/2012 12:32 AM, Thomas Martitz wrote:
Am 09.01.2012 02:26, schrieb Matthew Brush:
Hi,
This is regarding the change from v0.21->1.22 for the next release.
I totally agree that by now Geany has been long stable enough to have been in a 1.x series (or more) of releases, but I'm just wondering now about the jump. There's been some fairly majour and intensive changes since last release:
- Complete re-write and cleanup of the highlighting/scintilla mappings
code.
- Switch to entirely GRegex/PCRE from old GNU regex.
- Switch from Glade 2 generated code to Glade 3 / GtkBuilder XML.[1]
- Translation changes for this
- Massive changes to filetypes for color scheme support.
- Default themes not compatible with existing filedefs.[2]
- Lots of other stuff.
I think considering the massive amount of user-facing changes that have occurred in the last cycle that it might be misguided to jump to a 1.X version in declaration of "being stable". I'd argue in fact that while there's been some really awesome improvements, we are far less "stable" than in previous versions.
Is that true? Does Geany really crash or show glitches _more_ often? Are there many regressions over 0.21? It's not like 0.21 is 100% stable. And, what's more important, can't the bugs be worked on until the release?
It seems like the vast majority of our bug reports come from distro package users and Windows release users, so it's possible that some/many newly introduced bugs won't be found until after a release.
Since we haven't released with the new versioning scheme, IMHO, it would make sense to jump to something like 0.98/0.99 in preparation for the next cycle, rather than a whole 1.00.
IMO this many intensive and user visible changes make the 1.x even *more* justified.
I agree it justifies a big version bump, I just wonder about doing a majour version bump because "it's so stable", when like I said, it's possibly less stable, in the sense that there's been lots of big changes. If we were just bumping to 1.0 in the name of breaking compatibility, I wouldn't think anything of it, but since we're jumping a whole majour version and then skipping 22 minor versions due to Geany's "stability", it's why I question.
[1] Don't under-estimate this, while 100% necessary, it's not just for the code changes which weren't really that big, but for the build-system changes, the added file dependency for the UI XML, the exporting of a bunch of new symbols (-Wl,--export-dynamic and G_MODULE_EXPORT) and interactions with plugins (there was recently a bug due to this in GeanyLatex)..
What do build system changes, dependencies and exported symbols have to do with the version number? These are not user visible and should affect the stability. As for plugins, well it's the plugins job to keep up with
These changes can cause some very subtle bugs, as we found with GeanyLatex. It could affect some weird corners of plugins that might not get a lot of testing between cycles.
Geany development. I would dislike if Geany would take a step back/slow down just because the plugins aren't fixed in a timely manner. They're external and not part of the core for a reason.
I never said take a step back/slow down, I just question the reasons for our weird and massive next version jump.
[2] This is going to be a frequent bug/issue: "My colours don't work". The answer is that they have a customized filetypes.* files overriding the newly mapped named styles and messing with highlighting. It's an awesome upgrade in functionality but I *guarantee* it will be a source of numerous bug reports.
Incompatibilities are not unusual for major version changes. In fact, they're many times the very reason for that. So I'd say this is one another reason to finally do the change to 1.x.
Yeah, I agree with this, but again, I just question the "toggling the majour number" to signify how stable Geany is. If we went to 1.0 at least it'd indicate majour changes and nothing more, but we're making a point of just flipping the majour version number to indicate stability and keeping the minor number in step with the old one.
Conclusion: The list of changes speaks actually even more for doing 1.x. And the release isn't soon (is there actually a planned date) so remaining bugs can be fixed.
Yep, we will certainly, us small percentage of total Geany users that test new code in Git, continue to fix bugs until the next release.
Conclusion: I just don't want us to do a weird version change, which will no doubt be asked about numerous times, in proclamation of "because it's so stable" and then release possibly one of the more buggy versions (at least in the sense of number of bug reports, not even necessarily actual bugs).
Cheers, Matthew Brush