I think Elgg's plugin system is uniquely powerful such that it's really impossible to promise "strictly API additions" won't affect existing plugins in any way.

I suppose we could try to make that more clear? I don't know that it helps.

I agree with much of what iionly is saying, the fast release schedule is fine for hobby projects but many of the commercial projects I've worked on (especially for institutions such as universities) have very strict requirements for testing prior to pulling the trigger on an upgrade.  Forcing upgrades for security fixes certainly wouldn't work for those clients.

May be we can extend the security support for other branches. May be 2 more years for 1.x of bugs fixes and security fixes?

There are some plugins that are preventing me from upgrading to 2.0 (SNA4Elgg being one of those). It is not easy for a developer, now imagine how hard it is for someone that just needs a communication tool.

@Steve: of course there's no guarantee that a change in Elgg core doesn't result in problems for 3rd party plugins (even if completely unintended). That's not what I mean. The question is if it's really necessary to publish each new feature asap or if it wouldn't be better to bundle such changes within a release cycle at certain intervals allowing the plugin devs to breathe in between and also to provide an easier to follow changelog for end-users of Elgg and 3rd party plugins - especially inexperienced users.

The question is how to get a compromise between the interests of different groups of users. Who requires new releases to be made at the highest frequency possible in the first place? And wouldn't it be a possible alternative for these people to manage their site via composer (possibly independently of a strict release cycle)?

There's the elgg-starter repo for composer installs that is supposed to be in sync with the zip releases of Elgg once Elgg 2 is finished. How about an elgg-poweruser repo that's in sync with the head of the most recent development branch (or maybe rather the current 2.X branch instead of the master branch)? Then everyone could be happy: people who want every new feature immediately can get it (with a slightly higher risk of issues with 3rd party plugins) and also people who prefer a more conservative release cycle with possibly slightly longer release intervals (which would also lessen the effort necessary to make the releases).

@RJ: I think there's an important difference between bugfixes and security fixes.

Still, the question is how long 1.12 will get support. For the previous releases the security issues support was (is) provided for 1 year and bugfixes for 3 months (i.e. until the next 1.X release). As 1.12 is supposed to be the last 1.X release the question is how long to provide bugfixes for it.

When can we break off 2.x?

I wanted to avoid it until 2.0.0 for motivation to wrap up that release instead of moving on to 3.0 work...