Looks like a start of an interesting discussion. I'll chip in just a few drops at this time and won't repeat myself in terms of personal preferences for the version numbers because there are other concerns to take into consideration there, as well.
The release management need not necessarily be tied to the development and code branching strategy. Here is an interesting model that I've tried to emulate in practice but never got as far as having the full spectre of branches in a repo (mostly because I never had git in professional projects and Open Source ones are fairly small for the full model :'( ). It is interesting, nonetheless, to read into it and utilize the ease of switching and merging branches git provides. http://nvie.com/posts/a-successful-git-branching-model/ In brief, you could still have two main branches: unstable and stable. There are numerous other branches in practice. The feature branches merge to unstable, while hotfixes merge to stable branch. In this model, master is the stable branch, the mirror image of the GnuCash branch stability, but the practical difference is just in branch names. The code flow is likely still the same. What I find quite practical with git is that there can be lots of active branches that span from the main two - unstable and stable - and are used for new feature development or bug fixes. An opposite, perpendicular approach would be a branch per version number. This model is more oriented towards end-users and, in my opinion, makes more sense for large providers with a large and profitable user base. This seems very demanding on the development team as well as the release management process. As far as product management goes, with release version numbers, there will be lots of factors, I guess. As you mentioned, supporting certain versions in order to follow other vendors' policies might be one. But, politics aside, what I find practical for the release schedule GnuCash follows at the moment, is to have the version numbers still provide the information with semantic versioning but not necessarily providing much overhead in terms of maintaining the code branches. What I mean is, the numbers increase like on a measuring device. The third number (bugfix) releases happen only until the next minor version comes out. Then this becomes the latest version and bugfixes are release only for this version. I.e. - you do some work -> release 1.0.0 - features are being developed in feature branches - bug found. Release goes out, not waiting for the features to be complete. -> 1.0.1 - one feature complete -> 1.1.0 - another bug fixed -> 1.1.1 - big feature complete -> 2.0.0 - another bug fixed -> 2.0.1 and so on. There are several aspects here. Once a minor release is out, the maintenance is only done on that latest release, not on any of the previous ones. Users are expected to upgrade because there are no breaking changes involved. Releasing a major version might be a different story but in the simple case everything goes just like with minor version. Whether and for how long the previous versions are supported in practice depends on several factors: - the amount of development overhead and effort in maintaining the previous releases, - the amount of time/effort that goes into testing the future releases (meaning how stable they are in their x.0.0 version). Maintaining several active versions requires decent amount of testing of *all* of them and I am not a big fan of that scenario. That grows the efforts exponentially while providing a questionable result. You'll have to weigh on whether the results are worth the effort. The versions also do not need to be scheduled, although that's a nice touch when I look from the end-user's perspective. You could simply release whenever there are some updates. This gets both the features and bug fixes into production faster. Which is not necessarily always a good thing. These are just some observations that may or may not apply to GnuCash. But I always enjoy the discussion about these matters. :) -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
