Support of minor branches

Several months ago we reached an informal consensus that we'd provide "long term support" to the last minor branch of each major branch, which would look something like this.

This sounds great, but with the availability of core developers realistically we can't afford to maintain so many versions. Given also that we're much more compliant with semantic versioning, we feel there's no need to keep supporting (non-LTS) old minor branches. So we're considering only supporting the last minor branch of the latest two major releases.

In effect, if you're on 2.0, and you want a bug or security fix, you would need to upgrade to the latest 2.x release, which I think most users would now agree is a safe operation.

If the bug appeared in 1.12 we also release 1.12.x (for LTS) and most likely the fix would get merged up through the minor branches.


  • I think that makes sense. Having 1.10, 1.11 and 1.12 was excessive given there were no breaking changes. I think this will also give plugin devs a green flag to use latest APIs without worrying about past minor releases.

  • I agree on the assumption that it is technically save for plugins to always update to the latest minors of Elgg. However every minor will also provide new (small) features. Not every community will want to have these new features (or want to do a change every 3 months), because they could be user facing (which require more attention). Previously they could be a bit more relaxed when they update. This new proposed LTS will force them to update because of security reasons.

    So from a developers perspective i have no problem with the proposed support terms.

    From a system administrator (or community manager) view the user facing changes are maybe a bit too fast. But maybe this could be solved by separating plugins into separate repos that a sysadmin can keep on lower versions, but update Elgg (core) on the quarterly schedule.

    I also think that we should agree on the need to be able to update from every minor in a major to any higher minor in the same major. So it should be possible to go from 2.1 to 2.9 without the need to go through all version in between.


  • We're currently supporting 1.12 with security releases until 4.0. So, theoretically a vulnerability could trigger releases on 1.12, 2.0, 2.1, 2.2, 2.3, 3.0, 3.1, 3.2, and 3.3. This doesn't seem reasonable to me, at least with the current release process.


  • Sorry, if this sounds like being a spoilsport, but the only suggestion that comes to my mind is reducing the number of minor releases (e.g. 3 months --> 6 months) resulting in less releases to provide security fixes for.

    The problem I see with providing security fixes only for the latest current minor release (plus LTS release of former major release) is that it's simply not enough to say "theoretically there shouldn't be any issues with updating to the latest minor release with semver policy". This might be true when using only Elgg core and bundled plugins. But who does that? As soon as 3rd party plugins are used there is a certain chance (even if minimal) that a plugin would need some update to work on a more recent minor release. And with security issues in mind you would need to update to a new Elgg release as soon as possible once a new release containing a security fix has been published. But it might take some time to test a new minor release together with all 3rd party plugins used to be sure that there are no issues. And this is just not practical for everyone (maybe even more so for larger sites with a stricter administrative management in place).

    In the end, I see only the reducing of minor release numbers / increasing the release interval of minor releases as a solution.

  • the only suggestion that comes to my mind is reducing the number of minor releases (e.g. 3 months --> 6 months)

    Some of us want to use the latest and greatest. The motivation to contribute to Elgg core decreases if you have to wait several months before you can actually start using the changes you've made. I've been using Elgg 2.1-dev on three different production sites for several weeks now even though it's not released yet. I wouldn't want to wait another 3 months to get the stable version out.

    However every minor will also provide new (small) features.

    it's simply not enough to say "theoretically there shouldn't be any issues with updating to the latest minor

    I'm opposed to adding new user-facing features in minor releases. So to me these comments sound like we just need to be more careful when accepting PRs for the next minor release.

    Could you provide a list of the changes (prefably in another thread) that have caused trouble for you in minor releases? That way we can learn from the mistakes and better avoid them next time.

  • Some of us want to use the latest and greatest.

    I fully understand the reasoning of that. On the other hand, having non-core devs in mind you can't expect them to have a full overview at any time of what is going on in Elgg core and what implication a change in core has on their site(s) with a variable set of 3rd party plugins (possibly even with non-published custom plugins). A big organization (regardless if company, educational institution etc.) surely has some kind of established process of how to deal with updates. And I doubt that they would update some software without thorough testing - possibly with the ONLY exception that an update is focused on fixing some security issue (there might be some considerations done in such cases between fully testing an update before rolling it out and fixing a security hole asap).

    I've been using Elgg 2.1-dev on three different production sites for several weeks now even though it's not released yet.

    That's a practice surely not recommended for everyone. As a core dev you have a much better understanding and overview of what's going on in development of Elgg core and therefore it's likely to be less risky for you to use a dev branch of Elgg core on production sites. But any less experienced user (or even users with a good IT background but not directly involved in the development of Elgg core) might better not follow this practice. On the other hand, if you are using a dev version of Elgg on production sites anyway I understand even less why it's necessary to have such a short release cycle for minor releases to be able to use the latest and greatest as fast as possible.

    The point is: the shorter the release cycles the higher the effort necessary to maintain releases in parallel. The sooner the support (specifically security support) for Elgg releases is stopped the higher the effort necessary for maintaining an Elgg site.

    Could you provide a list of the changes (prefably in another thread) that have caused trouble for you in minor releases?

    Actually, I haven't had any trouble personally. But I'm probably not a good example user because I use my own plugins almost exclusively with only a few 3rd party plugins of other devs. Therefore, I might have a different kind of perspective regarding possible issues turning up with 3rd party plugins due to changes in Elgg core. First, I can judge better if there are problems to be expected with my plugins when reading the changelog of Elgg core. And in case there are problem I simply fix them on my own.

    Also, it's not that I have doubts regarding changes of Elgg core made in minor releases resulting in BC issues with 3rd party plugins specifically. But I would say that it's different for people who are neither core devs nor deal with plugin development or might not have a deep knowledge about development in general - and by number they are surely the vast majority of Elgg users. They can resort to testing any new releases (core and plugins) to a large extend only. And they have to find a balance between using the "latest and greatest" asap and the time they can afford for testing. If it's only a matter of fixed bugs or some new features added, they might decide to not always use the very latest version of Elgg. But if they are pressured to always use the very latest version to get security releases the effort necessary for site maintenance might reach a point where they think about looking for alternatives to Elgg that promise less effort to handle. And - frankly speaking - less people using Elgg would also be kind of demotivating, wouldn't it?

  • Don't get me wrong. I really wound not mind if every Elgg branch out there would receive fixes - I would in fact very much welcome it.

    We however need to face the facts: The past 16 (!) Elgg releases have been made either by me or Steve. The past 50 (!!) merges from lower branch to higher branch have been done - again - either me or Steve.

    I don't mind supporting more branches than what Steve is suggesting in this thread. It's however way too much work to be taken care of just by two people.

  • Don't get me wrong either. I know that it surely had been frustrating to wait for a new minor release in the past with 1.8 and previous releases without a clearly defined release schedule. The question is what a good balance would be between end users and core devs.

    Current support policy would mean 9 releases to be supported in parallel with security fixes. A release schedule of 6 months would already reduce this number to 5 parallel releases. With only the latest minor release supported it would be 3.

    Maybe another aspect to consider: how often has it happened in the past years that new releases became necessary to be made for security reasons specifically? What takes the most time in maintaining the branches and preparing the releases? Is it the number of branches to maintain in parallel, or the number of merges due to the bi-weekly normal bugfix releases. Bugfixes are a different matter to a certain extend and only the latest minor branch is provided with bugfixes anyway. Nevertheless, merging commits every two weeks - even if there might be not many commits - might be costing much more time than the (hopefully rare) case of merging security related stuff to the supported branches. I know that the bi-weekly release schedule is another aspect of the "latest and greatest asap". But realistically, how often has it been possible to stick to the bi-weekly release cycle? 2.0.2 has been released over 4 weeks ago. Not that I'm complaining! I had been doubtful about the bi-weekly release schedule from the beginning and my suggestion was a monthly bugfix / 6-monthly minor release schedule from the beginning. As I don't know about the tasks involved when making a release exactly I can't judge about what would be the most promising time saver. Would it save more time to have longer intervals between releases (with the number of commits to merge for a release being higher) or would it cost less if the number of commits to merge at once would be lower but the merging being necessary more often?

  • Unless someone is willing to invest time, I say everyone can adapt to whatever makes life for Juho and Steve easier. Those who want to stay on earlier versions can spend their own time cherry-picking bug fix commits. The proposed approach IMO is reasonable and will be beneficial for everybody in the long run. I am not willing to put in any more time than I already do, so I find it unacceptable to argue that it would take me more time to support the sites that pay for my time.

  • This discussion is going a bit off topic... the question was to drop bugfix support for other than the latest minors in the last 2 major branches. I do not think this question should be fuel to change the release schedule. I would really like to keep a fast release schedule. If the support of out-dated version stand in the way of quick releases, i would not mind to accept only bugfix support for the latest minors.

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.