How regularly would you like to see releases happen?

Summary: The core team has voted and approved a 2-week patch release cycle and a 3-month feature release cycle.

I've been plugging away on to help make it easier for us to release more often. We're at a place, I think, where we could release much more regularly so that you're waiting only weeks for patches and months for features, rather than months and years respectively.

What is a good frequency for major (breaking), minor (feature), and patch (bugfix) releases?

Update (2014-05-10): Thanks, everyone, for chiming in. Lots of good discussion here and that is really helpful to get all these perspectives. Here’s my summary of the discussion so far:

Unfortunately there's no clear consensus on how often to release from the various branches. :( Bummer. That means whatever the core team decides will end up disappointing some people, which is less than ideal.

Motivations for frequent, regular releases:

  • Avoid code going unused for months/years
  • Encourages core contributions if people know their patches will be available sooner
  • Project looks more active, which improves trust and helps drive usage/contribution
  • Our current release process is a horribly negative cycle:
    • Releasing takes too much time which results in putting it off
    • More changes are included while we’re waiting for the release
    • Since more changes are in, we need to test even more thoroughly
    • We put it off even longer because people don’t have time to test + release
    • Releases get blocked on features that people don’t want to slip until the next release
    • They end up waiting anyways
  • Incentivizes automated testing, reducing long-term overhead
  • No frequency works for everybody. Better let admins have the choice.
  • Allows admins/devs to decide how often to update, rather than artificially limiting them.
  • Shipping is a feature.
  • Makes it much easier to determine which change caused a given problem.

Concerns about frequent, regular releases:

  • “non-breaking changes” really means “not-intentionally-breaking changes”. Stuff happens
  • The current test suite for Elgg doesn’t guarantee enough stability.
  • Evaluating and testing changes for a weekly release would be too burdensome.
  • You can already pull from git if you want bleeding edge update
  • Looks better to clients if you are up-to-date with the latest release, which won’t be feasible.
  • Frequent releases look bad. Suggests there are lots of bugs
  • Faster releases will result in unstable code
  • Current testing practices are not sufficient or non-existent
  • Some people feel very compelled to keep up-to-date with new releases
  • Discourages developers who feel like they can’t “keep up”

Obviously we need input from the core team as well because this is not a totally-automated process quite yet, but we definitely want to get there as much as possible so we're not holding back features or patches for trivial reasons.

We're moving to semver after 1.9 is released, so there will be 0 breaking changes to the public API until 2.0. You should never need to update your plugins until the next major release. We still reserve the right to break the private API at will, so be careful about undocumented "features" that you're taking advantage of. If you're doing this, submit a bug report to get it documented/supported as an official API.

Also: we are going to strive to keep release branches very stable so that nothing blocks releasing like we've experienced these last 5 years! This stability may mean your PRs take longer to get in, because we will not accept half-done features even with a promise of a follow-up PR to wrap things up. They need to be done before they get in. But hopefully that's ok because you can be confident that once they are merged in, people will actually be able to use them very soon afterwards.

My strawman suggestion:

  • patch releases once per week
  • feature releases once per quarter (1.10 in Sept 2014, 1.11 in Dec 2014)
  • breaking/unstable/risky updates no more than once per year (humble 2.0 release sometime in 2015).


  • Also, I would like to consider data migrations as major changes. Switching comments to entities is a great thing, but also dramatic and surely breaks some plugins no matter how hard we try. It also feels significant in that if we messed it up, it could result in data loss so is especially important for people to take backups. I would love to be able to encourage people to upgrade minor releases without having to take backups and test thoroughly. It should just be a lightweight no-brainer experience. Upgrading across major releases, different story.

  • Well, if more regular updates would come out that would be good. An update system would be nice to have with differential updates, so not the whole engine (with the possibility of a rollback, if you notice an incompatibility with your installation). That would help users upgrade faster and less agony on their end.


  • #Ewan, a good frequency to release is... early and often! IMHO the main issue is not WHEN to have a new release ready but HOW to produce that.
    As far as I know, Elgg development process follows a feature-based release strategy. It follows the Catedral model of development. If you would move to the Bazar model (with a time-based release strategy) certainly you'll get releases more often and (what is more important) will get more people involved.

  • @Gerard, I think we call that system "git". :-P

    But seriously. Lots of people use git as their deploy system for exactly those reasons. We haven't popularized it or officially supported the idea, but maybe we should.

    @Augusto, thanks. Sounds like the frequency isn't as important to you as the regularity, am I right?

  • Whenever is ready or something really important (Security Patches) comes along.

  • @Evan. To me it doesn't make sense that a release with almost five hundred tickets closed more than six months ago still is not released because a dozen tickets remain open! And I'm talking about a Release Candidate (which means that it wouldn't be a production release yet).
    Software will never be free of bugs. There will always a bug to find and fix. So, why wait so long?
    So, neither frequency nor regularity is so important than a real perception of  continuous improvement. Even if it's baby steps not giant steps.

  • @Evan, LOL. Sure I know git, but I don't think that is true for all our beloved users. I guess Elgg can have more of a windows type of update. Very automated, in the background and only deal with it when it goes wrong. Yes, I am lazy :-)

  • @Augusto Our scope has creeped way too far, but we've rejected a lot recently. Check those dozen tickets. These aren't trivial, some break a ton of JS, e.g.

  • @Gerard - that would require your docroot files to be writeable by the webserver, I don't like that idea.  I've heard (not first-hand experience) that that sort of thing has got wordpress some big security issues in the past.

    git is a one-line upgrade, but it's not user-friendly for non-devs who are scared of command lines...

    That said with simple to follow documentation a one-liner should be easy enough for anyone to follow.

  • @Matt, isn't that the same question as documented in the install instructions. Use 755 or 644 for the doc root. If the first is recommended, the webserver is already capable of writing to the docroot.

    So, maybe this closes one question. Only apply 644 to docroot :-)


This discussion is closed.

This discussion is closed and is not accepting new comments.

Feedback and Planning

Feedback and Planning

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