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.
Thoughts?
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by Raül Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
Off topic might be a matter of perspective. What I tried to point out is that the whole release process, branch maintenance etc. might contain some other time-killing aspects apart from the security fixes aspect that might promise to reduce the necessary effort even more than dropping the security fixes support for minor releases older than the most recent minor release. I just wanted to suggest to evaluate the whole process (not necessarily for a single release but over a certain period of time also with the number of releases that would occur based on the release schedule). I can't judge the time necessary per release / per period of time on my own because I don't have the first-hand experience. I just imagine (possibly wrongly) that the effort necessary specifically for security issues would not be that high because it seemed to have happened so rarely that security fixes were necessary at all over the last few years.
The 3 month release schedule for minor releases (and bi-weekly bugfix releases) seemed to me a much more promising time-saver if the schedule would be stretched (within reasonable upper limits). If 3 months is already the reasonable upper limit then there's no further discussion necessary indeed.
Of course, dropping security support for all older minor releases except the latest would reduce the workload for core developers. And it's not me who can ask for not reducing this fully voluntary effort. I just pointed out a possible consequence that I'm afraid might result from that: reduced support cycles resulting in an increased workload for people using Elgg for their site(s) resulting in these people starting to look for alternatives with a longer support cycle for stable releases resulting in less people using Elgg resulting in less people in need for developers for hire. Again, it's not me who needs to care about that as I'm not accepting any paid jobs anyway and just do it for fun. As long as the development of Elgg continues I'm happy. So, I guess that's all.
Even if the release process was more automated, I'd still be strongly inclined to supporting only the last minor version of each major.
If done correctly, the features added in minor releases do not break anything nor force sites to adapt new user facing elements. Therefore minor upgrades are by default a non-problem. The later 1.x releases might have had some little glitches, but that was because we were still in process of adapting Semver.
In case a site owner doesn't want to do a minor upgrade every three months, they can wait for the LTS version to come out before upgrading (1.12.x -> 2.3.x). A bit similarly as Ubuntu users can either upgrade to the next (short-lived) version right away, or wait for the LTS version: http://www.ubuntu.com/info/release-end-of-life.
FYI for anyone not familiar with the current release process, it is described here: http://learn.elgg.org/en/2.0/contribute/releases.html. Anyone (core team or not) can take care of almost everything related to the steps 1 and 2.
- Previous
- 1
- 2
- Next
You must log in to post replies.