Don't Fear the 2.0

For a long time I think we've been holding the idea of Elgg 2.0 up as this huge event where we have to make radical improvements in lots of different areas. This is partly because we know there will be backward incompatible changes, so we want users to get a big return on that pain of upgrading. We're also fearful of the backlash awaiting us for breaking plugins.

I think we should schedule 2.0 for April or July and not make a big deal about it. We don't have to do anything game-changing, but we can at least start executing on ideas that aren't BC. We can't avoid BC breaks forever and I think living with the pain of some of our past decisions is not good for the health of our community of code and design contributors.

  • i prefer the tried and tested (in commerical circumstances) approach of:

    • major version number changes representing major overhauls/upgrades to the base framework and features.
    • minor version numbers representing alterations within the existing base framework and minor new features.
    • 3rd version numbers representing bugfix releases.

    my vision of a major version change for elgg would be along the lines of: 'elgg now contains a similar feature set to the major social networking platforms', such as social engine, oxwall and facebook etc.
    for example, live notifications, ajaxed ui and graceful operation.

    chopping and changing the versioning approach is not helpful here.

  • As of 1.10 Elgg switched to Semantic Versioning. TL;DR: We try damned hard to not break any plugins between major versions and ideally you can upgrade patch and minor versions safely. Elgg is built by a small group of volunteers and available dev-hours varies wildly even from week to week, so in general allowing Big Features to block releases doesn't work for us. Blocking on features in development was why 1.9 took sooo long and frustrated devs who contributed code just to have it sit for months/years.

    Re: expectations of shiny new stuff, simply put, Elgg is a large application with a small team working on it. Hence the progress must lie on a spectrum: On the left there's slavishly caring to keep 3rd-party code running (please existing users); on the right there's moving quickly while breaking all 3rd party plugins (please brand new users). There's no free lunch.

    1.8 (which would've been a major release today) made a lot of people unhappy (particularly plugin devs who we also lean on to contribute core core), but was necessary. IMO we probably should lean more to the right again to jump into the modern development world, but it will tick off a ton of people. Although that builds bad will with developers who depend on Elgg being a stable thing, so does having a crusty "web 1.9" design, even if it is responsive now.

     

  • @iionly You really shouldn't need to check your plugins that often (especially anything upgraded fully for 1.8), but yes that's the only way to be sure.

    I like that WordPress lets end users "vote" on which plugin versions work on which releases. That might help crowdsource your testing.

  • thanks for the explanatory link steve; the semantic versioning pattern is essentially my preference too. my issue is that i am finding lots of changes that were needed between 1.8 and 1.9 code, across many plugins and so the 'backwards compatible' aspect is a bit blurry for me here. i appreciate this is a lot of code to handle and i am not complaining, so much as just wanting to express some concern that maybe there is a perception that the shift from 1.8 to 1.9/10 is simpler than it is in practice (depending on what plugins sites are using).

    i see where you are coming from with the numbering now and ultimately the numbers are just that.. only numbers.

  • If a large amount of dev power is constantly bound by keeping plugins up to date these resources are missing in core development, too.

    I surely don't want to suggest that BC compatibility must be guaranteed for all time. I'm just saying that I really have no idea what 2.0 really means and that it might be useful to think about the direction Elgg might take not only on the short term but also have at least some rough plan outlined for the mid term/long term. This doesn't necessarily mean that "feature x" is planned to be added in version "x.y" but it might already help to know that a certain feature / code rewrite is planned to be added / done in near future and therefore it would be useless to make any other changes in this part of the code just now.

    What would Elgg 2.0 look like if it would be released in April (earliest date scheduled)? What would that mean for the bundled plugins? Would they need to be heavyly modified? If yes, how is April a realistic release date for Elgg 2.0? If not, does that mean that 3rd party plugins wouldn't have to be modified heavily either?

    What about the wrapper API mentioned by Evan? Would that be a solution not only for bundled plugins but also for 3rd party plugins? And wouldn't such a wrapper API be a new feature / blocker for the release of Elgg 2.0 that would be worth waiting for? But as I already tried to point out before it would be necessary to make at least a rough plan for the content of 2.0 before thinking about a release date. Maybe such a plan already exists. Then it would be nice to give us non-core devs an outlook, too.

  • @ura I argued that 1.9 actually be released as "2.0", because there were clearly going to be breaking changes. I lost that argument on the notion that we would start SemVer after 1.9. Again, I see that a result of putting too much pressure on what must go into a 2.0 release.

    @iionly Frankly there's no master plan, but there are several wishlists out there (and hundreds of them already in the GitHub issues). We definitely need to up our game in the planning area to gain consensus on direction.

  • Related to migration issues; as @steve mentioned, Elgg only has semantic version since 1.9, so 1.10 is the first release where the benefits of semver should show, and by my own experience it is wonderful. Recently i build a site on 1.10 and all plugins (which worked on 1.9) still work on 1.10. This is due to the effect of semver but also related to better (automated) testing of code. There is still a lot to improve in that process, but this is very promising. At least there should be no month of work anymore to update your 1.9 plugins to 1.10.

    Related to 2.0: This discussion should be on what we want/need in 2.0 as we can't do it all. We need to be selective about it, because i rather want 1 good improvement, versus multiple half baked solutions.

  • I appreciate you guys displaying deprecated messages for our plugins so we know exactly what functions need to change in our code. Also plugins breaking in 1.7 and below were a nightmare!

  • @elgg/core how do we proceed from here? I really like to see at least a small roadmap of things that people are actually going to work on for 2.0 (so not assigning item to 2.0 only because they contain a BC break). Maybe we should first set a date and then we could assign github issues to 2.0 and to ourselves to indicate some commitment on getting it in before the given date.

  • I'm fearing 2.0.  Not for any logical sense, but because of the hype that it may be a major upgrade similar to 1.8.  I know the new codebase is much better, but for someone who is not an expert at coding, it threw me off to the point where I abandoned my elgg project. Either way, what the development team has accomplished with this project is no less than phenomenal and I am forever grateful.  This is an amazing code

Feedback and Planning

Feedback and Planning

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