I've been thinking that we should change the way we augment the Denemo version number, to avoid those who are following the development having problems when they upgrade but the version number stays fixed. (And to make better use of the numbers available).
I propose that each release in future augments the minor version number (except if we ever create a major new version of course, in which case we would augment the major version number). So the next release will be 2.1.0 after that the development version will become 2.1.1 and the last number can be augmented whenever the menu-system has been altered and whenever there is some significant change that it would be useful to have labelled. To avoid any confusion, I propose the micro-version numbers should skip even numbers for development versions - so once I have the current work ready I'll commit it with version set to 2.0.17 and continue on the odd numbers until we are ready to release 2.1.0 Jeremiah, Andreas, Tobias, Edgar - is this workable? - will your overnight builds continue to work ok as the version number changes? This change will come at an opportune moment, since the next release is intended to remove Gtk deprecated code, which will place us in a good position for GTK4. The only caveat is the threading primitives which are deprecated - I don't understand that code, so I'm not sure if I will succeed in moving it on. I wonder if we could crowd-fund a threading expert to do this? Richard _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
