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 https://github.com/Elgg/Elgg/issues/6783 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:
Concerns about frequent, regular releases:
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:
Discuss.
This discussion is closed and is not accepting new comments.
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.
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 :-)