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.