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.

  • Balancing BC with moving forward is the name of the game, but at some point you need to take bigger jumps to get bigger gains :)

    I've been short on contributing time lately unfortunately.  Thankfully other people have still been around and plenty active.  I agree with Jeroen that we should try to come up with some definitions of intent for 2.0, lest it remain just a nebulous "elgg with breaking changes" concept.

  • I would reiterate that the problem with roadmaps for this project is that our tiny team of volunteers doesn't typically have the resources to actually commit to any such thing. They're not bad in general, and I know everyone wants them because you want to know what is coming, but that just is never going to happen given the status quo.

    If you personally have time to plan out a personal roadmap of goals you'd like to accomplish for 2.0, then by all means present it to the community and we can review your PRs and such.

    The best we can do probably is decide on a general direction for the project and then accept/encourage PRs that move us that direction. But we can't put features on a timeline. We're just not that kind of project, unfortunately.

    Main theme for me continues to be "reduce the customization/maintenance burden."

    • Installing/updating Elgg core should be made trivial via composer (ideally Elgg core would be installed like any other composer dependency).
    • Make it easier to have site-specific modifications that aren't released/packaged as a plugin
    • Expose DI framework to plugin devs to encourage writing tests for their code

    @iionly I would hope that moves like these decrease your maintenance burden substantially over time, increase your confidence in your code, and possibly even help enable you to make your code more portable outside of Elgg.

  • @evan i agree on not being able to commit to a given roadmap, but we can commit to a certain timeline. If core wants to change things that are breaking (and we have a lot of tickets waiting for that), we should just mark a certain point in time, so devs can contribute to that change.

    The benefit of the time based release schedule that we have for 1.x is really good for the ROI of the devs time as he knows that if he/she changes something they will get it in a certain amount of time. If we do this also for the 2.0 release we can assign tickets to it that need to be in the 2.0 release, so devs can invest time in those tickets if they have the time.

    Every dev has its own interest in what he expects of or needs in 2.0. Let them decide what to work on and work towards a release candidate around June.

    So to come back at your comments:

    If you personally have time to plan out a personal roadmap of goals you'd like to accomplish for 2.0, then by all means present it to the community and we can review your PRs and such.

    I am happy to do so, but only if i see my invested time release in a reasonable amount of time.

    But we can't put features on a timeline

    Yes we can, but we can't commit to them. If it is not added before date X, drop it from the list.

    Main theme for me continues to be "reduce the customization/maintenance burden."

    By accepting all kinds of PR's for 2.0 the project will grow. If this is your contribution i would be very glad.

  • I think the main focus of 2.0 _should_ be about deprecating APIs and upgrading all core and bundled plugins to the new APIs. I still think we need to focus on using what we have currently instead of adding new features. 2.0 should be a chance to refine these APIs, remove the cruft, and update our own code to meet our own expectations. 

    When I bring new devs into our Elgg instance, some of top questions are:

    1. How should I include JS? The docs say to do it one way, but the bundled plugins do it different ways.
    2. How do notifications work? Why does notify_user() send an email immediately, but registering for notification events not?
    3. Where do classes go? (Or worse, should I use classes?)

    I love new features and new APIs that make life easier for me, but right now we don't have a solid framework because core itself is split across so many ideas. As a new developer, there is no apparent cohesion to the API because the code argues with the docs.

  • Maybe "roadmap" is too strong a word or the usual meaning might not fit exactly to what I want to express here. I am aware that a "roadmap" makes not much sense for a time based release schedule and for a non-BC-breaking minor release it's perfectly alright to say that if a feature isn't finished when the next release is due date then it will be postponed until the release after that.

    But a BC-breaking major release is different at least in terms of "you don't want to have it too often". If a BC-breaking modification isn't finished before the release date then it might take much longer until it gets merged (or it gets frustrating if the next BC-breaking release comes soon after the last). So, some kind of roadmap - as minimalistic as it might be in the end - seems to make sense to me even for a time based release schedule for BC-breaking releases. Also, when reading the replies in this topic I get the impression that there are currently different ideas regarding what Elgg 2.0 should be about and these ideas seem to contradict each other at least partly (beg your pardon).

    A roadmap (only including BC-breaking stuff) could help

    • for every core dev and also 3rd party plugin dev to get an overview of the BC-breaking stuff that is already ready to be released (in master branch?) or has any chance to be finished for 2.0. Maybe it's perfectly clear to everyone what will be the changes in 2.0 but it's not to me at all and I have no idea what the changes will mean for existing 3rd party plugins.
    • get an idea of how the different BC-breaking changes might influence each other (it might turn out that some more BC-breaking modifications are necessary on the short term to get them working together).
    • help to plan what you intend to code not only until the release of 2.0 but also afterwards (it might make sense to work on a BC-breaking modification now even if it has not much use in itself but it allows to make non-BC-breaking modifications in the following).

    If the roadmap (not a wishlist) would be made with a release date in mind and only contain a minimum number of topics (that have a realistic chance of making it in the 2.0 release candidate) then it could help to get an idea of what 2.0 is about. If it turns out in the end that a certain topic won't make it in 2.0 then it won't be the end of the world either. On the other hand, a little bit of planning when the release date of 2.0 is not imminent yet might help to reduce the expectations of what can be achived to a realistic level or might help to agree on a realistic release date (i.e. changing it +/- a few months definitely and surely not postpone is unnecessarily).

  • @iionly

    there are currently different ideas regarding what Elgg 2.0 should be about and these ideas seem to contradict each other at least partly (beg your pardon).

    No need for apologies. This is quite a valid observation.

    @jeroen, fully agree with your conception of how a timeline should work. Glad we're agreed there. 


    It seems to me that the most practical thing we can do at this point is just pick a freeze date for Elgg 2.0 and agree to stop accepting breaking changes after that date by branching to 2.x, 2.0, and starting on the betas/rcs track for 2.0.0. Breaking changes that don't make it in by the agreed upon date just slip to next major release (like all our other releases) and can continue to be submitted on the master branch.

    Here's my proposal for release timeline over the next few months:

    • 1.11.0 on April 12 (We only had 1 rc for 1.10 and it didn't turn up anything. I vote we just skip the rc this time and let the bi-weekly patch releases do their thing)
    • 2.0.0-beta.1 on May 3 (early preview, still allows for breaking changes)
    • 2.0.0-beta.2 on June 7 (early preview, still allows for breaking changes)
    • 2.0.0-rc.1 on July 5 (No more breaking changes allowed on 2.x, rcs every 2 weeks until stable)
    • 1.12.0 on July 12 (Last minor release of 1.x series)


  • @ewinslow sounds like a good plan!

  • @ewinslow I like it. Can we repost it somewhere more prominent?

  • Let's get a few more affirmative votes and then we can post it on our blog as the 2015 roadmap

  • SGTM. And Evan, I am really happy you are on top of things ;) Thanks for driving this massive dev effort.

Feedback and Planning

Feedback and Planning

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