Re: On development/release processes and version numbers
> On Jan 25, 2018, at 5:42 PM, Glen Ditchfieldwrote: > > Regarding EOL management, I think you will soon have three supported > "product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20, > ...), and a 2.4.x series. (The level of support might be something > low like "security fixes only".) 3.1 will likely come out before 2.6.x > reaches end-of-life. > > If that is correct, you'll have to be able develop bug fixes that don't > apply to all of the supported series. I don't think that will be easy > if you have just one bugfix branch. > > I looked around and couldn't find any helpful Git advice for projects > that have more than one supported version. Every detailed work flow > seemed to assume that there just one blob of current production code, > and one development branch. > > Perhaps this would work: > * Normal development (refactorings, enhancements, etc) goes on master. > * Every supported series has a branch: for now, create releases-2.6.x > and releases-2.4.x. Bug fixes accumulate on these branches. > * Use feature branches for development: every enhancement and every > bug fix gets its own branch. Enhancements branch off from master. > Bug fixes for old versions branch off from a releases-* branch. > * When the time comes to prepare for the GnuCash 3 release, create > branch releases-3.0.x from master. Make any necessary adjustments > to the releases-3.0.x branch, and tag the result as v3.0.0. Any > work done on master after the branch will be part of v3.1.0. Nope. We do a final release of the previous stable branch concurrent with the first release of the new stable branch, so 2.4 stopped with 2.4.14, released the same day as 2.6.0. 2.6 support will end with 2.6.20 that will be released with 3.0, and 3.x will be the only supported branch until we start a new unstable release cycle in 4 years or so (unless we decide to change the “major” release tempo). There’s a reason that you couldn’t find much about it: It’s rare because it’s hard. Even projects that have lots of developers like the Linux Kernel don’t do it. Resource constraints aside, the problem with having more than two branches or with letting parallel branches live too long is code divergence and up-merges. Merging maint into unstable is already a major pain-point and I’ll be really happy to get 3.0 out so that we don’t have to merge from what will then be the 2.6 branch any more. If the pace of master development picks up we may have to accelerate the “major” release tempo to avoid up-merge problems from converting the main engine classes to C++. We’ll see. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: On development/release processes and version numbers
As a Noob following this with interest: 1. If a platform makes a decision that breaks a previous stable version, it could be a case if create a quick fix branch off that version tag, and release an extra ".1". So 2.6.1 would become 2.6.1.1. Note that I am assuming that this is rare and that most people are keeping up to date with stable releases (so most bugs are off that). 2. Ultimately, it sounds like step 1 (regardless of which version control labelling is used) is to try to automate as much of the "release process" as possible. This frees up time from an experienced coder. Should we have a separate part of the source code for release scripts (that the release manager can just run)? Is this something that people like me can help with? (Not that I know enough yet to be much help...) Thanks and regards, Matt Original message From: Glen Ditchfield <gjditchfi...@acm.org> Date: 26/1/18 12:43 (GMT+10:00) To: gnucash-devel@gnucash.org Subject: Re: On development/release processes and version numbers Regarding EOL management, I think you will soon have three supported "product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20, ...), and a 2.4.x series. (The level of support might be something low like "security fixes only".) 3.1 will likely come out before 2.6.x reaches end-of-life. If that is correct, you'll have to be able develop bug fixes that don't apply to all of the supported series. I don't think that will be easy if you have just one bugfix branch. I looked around and couldn't find any helpful Git advice for projects that have more than one supported version. Every detailed work flow seemed to assume that there just one blob of current production code, and one development branch. Perhaps this would work: * Normal development (refactorings, enhancements, etc) goes on master. * Every supported series has a branch: for now, create releases-2.6.x and releases-2.4.x. Bug fixes accumulate on these branches. * Use feature branches for development: every enhancement and every bug fix gets its own branch. Enhancements branch off from master. Bug fixes for old versions branch off from a releases-* branch. * When the time comes to prepare for the GnuCash 3 release, create branch releases-3.0.x from master. Make any necessary adjustments to the releases-3.0.x branch, and tag the result as v3.0.0. Any work done on master after the branch will be part of v3.1.0. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel=02%7C01%7C%7C398a5e971c26478e833508d5645e22fc%7C84df9e7fe9f640afb435%7C1%7C0%7C636525277829194997=jxw9jYSj39B%2B%2ByIsE7ElE8fwm5d6pNFie3JU%2FMpEph4%3D=0 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: On development/release processes and version numbers
Regarding EOL management, I think you will soon have three supported "product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20, ...), and a 2.4.x series. (The level of support might be something low like "security fixes only".) 3.1 will likely come out before 2.6.x reaches end-of-life. If that is correct, you'll have to be able develop bug fixes that don't apply to all of the supported series. I don't think that will be easy if you have just one bugfix branch. I looked around and couldn't find any helpful Git advice for projects that have more than one supported version. Every detailed work flow seemed to assume that there just one blob of current production code, and one development branch. Perhaps this would work: * Normal development (refactorings, enhancements, etc) goes on master. * Every supported series has a branch: for now, create releases-2.6.x and releases-2.4.x. Bug fixes accumulate on these branches. * Use feature branches for development: every enhancement and every bug fix gets its own branch. Enhancements branch off from master. Bug fixes for old versions branch off from a releases-* branch. * When the time comes to prepare for the GnuCash 3 release, create branch releases-3.0.x from master. Make any necessary adjustments to the releases-3.0.x branch, and tag the result as v3.0.0. Any work done on master after the branch will be part of v3.1.0. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: On development/release processes and version numbers
For clarification, Ubuntu supports their LTS for 5 years, (both desktop and server) but they release one every 2 years. Debian adopted a similar approach, but the two are a year out of sync. As most know, Ubuntu uses a date based version numbering scheme with point releases for bug fixes. Debian also uses a timed-release model, but they use x.y.z notation instead of yy.mm.z RHEL offers standard support for 5 years, but they have 3 additional support levels topping out at 10 years total, with the option for special add-on support long beyond that. (for the right price I’m sure) I didn’t check their release cadence against Debian/Ubuntu. Libreoffice also uses a time-based release x.y.z scheme where ’x’ is the next major release (in their case, every 2.5 years), ‘y’ includes new features and is released every 6 months (supported for 9) and ‘z’ is a monthly bug-fix release. They support 2 released x.y versions at a time (for about 9 months each) with a third being always bleeding edge as the next release. They do note that this process is resource intensive despite (or because of) their large team. I would think this has more to do with the tight schedule though rather than the general scheme itself. If the goal is to look ‘fresh’ for users, then I’d think a time-based numbering scheme is the way to go. (either by dates, or x.y.z) But if semantic versioning is more important, then you’re destined to appear ‘stale’ since development of major improvements is slow to occur due to a small team and limited resources. (not that I think anyone is complaining, everyone working on this project is much appreciated) Based on the GnuCash release cadence I would think a 2 year LTS policy would be sufficient to maintain with bug-fixes only, while all new features (even minor ones) and major changes go into the ‘fresh’ version. Two versions seems like the least amount of work and is pretty fair. There are two other topics that might assist with the ‘stale vs. fresh’ impression: reports and modules. Judging by the mailing list topics, it seems reporting is the area users care most about having as a new ‘feature’ than actual application functionality. Certainly, reports can be added or improved for the LTS users since they are able to be installed separately and don’t really constitute new ‘features’ in the main app. As long as the plugin-module model is supported, that route can offer ‘new features’ as well until they are integrated into main. With those two in mind, the LTS policy could even be 5 years since it would be possible to add-on needed improvements while the core dev work is on toolkits, MVC, language rebasing and moving to full database usage. (those report writers and plugin maintainers would have to keep up with the ‘fresh’ version of course, maybe even merging into it for the next major release, but their original code will last as long as the LTS policy) Just some thoughts, Adrien > On Jan 25, 2018, at 1:41 PM, cickowrote: > > 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,
Re: On development/release processes and version numbers
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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
On development/release processes and version numbers
To start, this will be a long read to introspect on our development and release processes, where they are now and where the may go in the future. If you want to help shape this future, please read on and share your thoughts. I have started a thread earlier with a proposal to update our versioning scheme for the upcoming major release. So far the short summary is that most agree we can switch to 3.0 rather than 2.8. The debate is still open on two related aspects: - should we continue with a 3-level number or switch to a two-level one - how should we indicate unstable versions: * via a distinction between even/odd number * via .9xx * via another extension such as alpha/beta (a/b)... Before bringing this to a final decision I want to make a detour to our development and release process ("our processes" in short from now on) as the discussion so far has lead in that direction regularly. In the end I believe whatever version number scheme we decide upon should reflect how we develop and release gnucash. Current situation: - we develop on two primary branches: maint and master. - on the maint branch we accept bugfixes and small compatible features - all other development goes on master. This includes major refactorings, incompatible changes (though we usually do our best to provide compatibility code in maint), big new features, important dependency updates,... - we do regular "stable" releases from the maint branch (once every 3 months, or once every month early in the stable cycle) - we never release from master. Near the end of a major cycle (which is not strictly defined) we branch off a separate branch to stabilize whatever is on master at that point and do beta releases from that separate branch (monthly). However due to our current version number scheme users and distro maintainers seem to believe we have 3 levels of development, usually seen as - bugfixes - new features (I'll refer to those as enhancements from now on to avoid confusion with our current use of the term 'feature branch') - incompatible changes I personally care more about stability than about a distinction between pure bugfixes and enhancements. Others appear to believe the former can only exist thanks to the latter though. Some distros have strict bugfix-only policies in stable releases. This conflict between actual development process and user perception was one of the reasons I started this whole version proposal. Originally it didn't even occur to me we could question our processes. I immediately proposed to switch to a 2 level version number. And even when others pointed out the other possibility my knee-jerk reaction was still adjusting our processes to accommodate 3 levels would increase the maintenance burden too much. But does it ? Let's do at least the thought experiment. What assumptions do we have about our processes that may no longer be relevant now ? Below I'll put up an alternative process for others to think about. It's not intended to be the perfect solution, but something to start the discussion. 1. A 3-level development model would require 3 rather than 2 primary branches in git: master (as now), enhancements (for compatible enhancements) and bugfixes (for guess what). In the svn days, everybody would cringe even at the thought of having yet another branch to maintain. However in git this has become relatively painless. There are still merge conflicts but git really goes a long way in making multiple branch development pretty manageable. So having a 3-level branch strategy would be realistic. bugfix would be the oldest branch. Everything committed to bugfix would eventually be merged upwards into enhancements. And all enhancements and bugfixes would eventually get merged upwards in master. So far so good. 2. But what with releases ? It starts simple: one does a bugfix release at fixed intervals from the bugfix branch, and enhancement releases from the enhancement branch. Both can have their own cadence. However it quickly gets more complicated when a bug needs to be fixed in a new enhancement. Now one needs a bugfix branch on the enhancement branch and this would happen again with the next feature release. So rather than one bugfix branch we'd need a bugfix branch starting at each enhancement branch release. Branch-wise git can still manage this perfectly fine. 3. So back to release aspect itself. Having more branches means more releases as well. As things stand each release takes a substantial amount of time from our release manager. I don't know the exact amount, but I know there's a long list of manual steps that have to be repeated for each release. If releases are not too frequent, this is acceptable. However if the number of releases increases, the time spent on doing them will become more significant and that would be time our valued release manager can't spend on actually improving gnucash. So that's an important question: can we automate