Elgg Blog: Elgg 1.9.0-rc.4 released

With slight delay in our 2-week release cycle, we're proud to announce that the fourth release candidate version of Elgg 1.9 as  availible for download. It's probably the last release candidate version before official 1.9.0 release so that's great occasion for especially intensive bug hunting. Please report all bugs in our github issue tracker: https://github.com/Elgg/Elgg/issues

This release closes all remaining issues blocking 1.9.0 release

    Features

    • discussions: Added email SMTP headers for better thread grouping. (91755a86, closes #6894)

    Documentation

    • i18n: internationalized the documentation (ff5fd9be, closes #5899)
    • upgrading: Added upgrade instructions for 1.8 to 1.9 (001e3ffa, closes #5900)

    Bug Fixes

    • aalborg_theme: selected page menu does not collapse sub menu (53f696ce, closes #6979)
    • collections: make urls work regardless of username (76827f22, closes #6059)
    • core: Added missing options array support for ElggUser methods (30d98c67, closes #6994)
    • deprecation: the deprecation wrapper correctly handles array access (264fc5f2, closes #7017, #6917)
    • discussion: no longer show entity menu items on non-discussions (d3c7c953, closes #6508)
    • file:
    • destroy output buffer before sending file (007021ff)
    • download adds header Content-Length (8375eb09)
    • groups: give feedback if a user cannot be added to a group (07cddc61, closes #6081)
    • install: Make installer usable on smartphones (b528d988)
    • members: prevent members search with empty query (12f7b88f)
    • notifications: Corrected html entities handling for email subject and body (4bfb849e, closes #6905)
    • release: Corrected release script Windows system compatibility (18f78403)
    • router: Can return 'handler' param in 'route', $identifier hook again (6e09758f, closes #6696)
    • rss: River entries include their full correct summaries again (96679d8b, closes #6901)
    • thewire: More effective textarea change detection (e07f6975)
    • ui: Corrected bad stretching of non-square, large avatars. Now upscaling by width. (71ea155b, closes #5602)
    • upgrade: test for ability to connect to localhost if rewrite test fails (7c49e4ce, closes #6888)         

    No release is possible without contributors:

    • Evan Winslow
    • Paweł Sroka
    • Matt Beckett
    • Jeroen Dalsem
    • Paul Shepel
    • Steve Clay
    • Adrián Chaves Fernández (Gallaecio)
    • JoseLGM
    • Per Jensen
    • Fatal exception while upgrading from rc3-rc4 #7033

    • Anybody noticed new e-mail notifications threading on community?

    • Yup. Working for me. Way better than before. Now i have some other peeves to report :)

    • "vendor" vs. "vendors" folder: the "vendor" folder was newly added. Has it been on purpose to not add its content to the "vendors" folder? If yes, is it really a good idea to give the folder almost the same name than an already existing folder? It might result in issues simply because the referred folder name / file path contains a typo.

      General question about maintenance of open issues at github: after all the milestones that were used only for maintaining the issues and sorting them in smaller bits (e.g. relevance for past / current / future releases) were dropped most issues are now without milestone but there are also quite a large number of issues without any labels that would indicate the relevance of these issues. Some issues might be obsolete in the meantime for different reasons, others might refer to issues that are not strictly blocking issues but still quite annoying. Has anyone recently checked if there are really no open issues remaining that might better get fixed BEFORE the final 1.9 is out? Or are there at least some ideas how to filter the large amount of issues in a better way to find out the more annoying issues among them if they have not been labeled in any way.

      Examples of issues I'm talking about:

      • https://github.com/Elgg/Elgg/issues/6422: breaks UI. The issue was included in the 1.9.0 milestone at first and has been partly fixed but then it has been forgotten to fix it completely and was removed from the 1.9.0 milestone without adding any labels to it.
      • Soon to be obsolete issues: https://github.com/Elgg/Elgg/issues/5938 and https://github.com/Elgg/Elgg/issues/6060. Two functions that were removed without any deprecation. Once 1.9 final is out and any plugin stops working it might be the easier / faster way to fix the plugin instead of waiting for a belated deprecation or fallback solution.

      Just a couple of examples of issues I opened. There might be other issues or maybe there are no other problems. At least I don't know how to be able to create a "shortlist" of pressing issues among the huge amount of unsorted open issues.

    • @iionly vendor dir is created by composer and I wouldn't like to mix up those two. I'd prefer to move all php libs to the composer config and as a result keep them in vendor dir and for JS stuff think of another dir managed by some js dependency manager like bower (which is perhaps controversial as there are different preferences from Evan IIRC). Typo in path is rather trivial error that affects only core team and ppl using composer, so I'm not worried about that really.

      According to reviewing issues, there are tools like http://www.codetriage.com/. Feel free to bump any important issues that fell off our radar or suggest labels. Anybody with write access to Elgg/Elgg can change labels and if you don't have access, you can always suggest labels in comment.

      We had plenty more ideas about 1.9.0 that were moved back to 1.10.0 so don't expect anything new to be added. There's also plenty of tickets moved to 1.9.0 which is after RC. If you have anything that looks like a blocker, please bump it directly by commenting on it.

      Lots of those issues are wish lists (like whole 1.x milestone) of things that are nice to have but not so important and often become out of date. From personal point of view, I have list of stuff that I want to get to but have not time/motivation to implement and in the meantime implement stuff that's important (bugs/blokers). Adding more items to that list, won't make it faster unfortunately, so it's more a matter of bumping priority.

      According to your tickets, I just closed them (no offence) with explanations. You're right, they should have got responded to and closed earlier. Also I spoke many times on our deprecation policy, so my main point is that we need better reason to keep particular function than "plugin X uses it". I'd much prefer argument like "plugin X has no other way of doing it and/or needs to fork good chunk of the core to handle it". We need to draw a line somwhere.

      I'd very much appreciate any initiative to improve issues triage, so feel free to work on it. Just keep in mind that just saying "hey guys, improve that" won't help as much as "hey guys, merge that improvement". In issues context that means  that I'd love to get comments on particular tickets needing attention (in our case labeling) or closing.

    • @Pawel: I'm not referring to new features or improvements that were now postponed to 1.10 but only to bugs (either new bugs introduced with 1.9 or bugs already in 1.8 or even earlier versions).

      And while there is a 1.X branch there is no longer a 1.9.X milestone. It seems to me the 1.9.0 milestone only contains issues to be fixed for the first final 1.9 (or in RCs). All other issues that were within the 1.9.X milestone are now without a milestone - and most of them without any labels. I'm just saying that I have lost the overview over all the issues that are now without any indication about their nature (bug / feature / core / plugin / UI etc.) and I'm just slightly worried that there might be some bugs already reported that maybe should be fixed sooner than later if anyway possible even if they are not so serious that they would be a blocker.

    • @iionly,

      vendor/vendors -- Pawel hit this.

      issue triage -- I've been trying to go through and sort out old issues a few at a time. Closing open pull requests is the most important thing to me. At least adding tasks explaining what needs to be done before we can pull it in is critical. Help is greatly appreciated. You, in particular, have been one of the most vocal and helpful contributors in this space.

      A brief rant about prioritizing issues:

      Unfortunately, priority doesn't mean much in a volunteer-based project (maybe not even on paid projects, if the list of issues gets long enough). Issues get fixed when people who are capable get motivated and fix them. For example, I was motivated to fix the extremely unexciting RSS bug because I wanted to see 1.9.0 get out the door. If we hadn't decided it was a 1.9-blocker, I would not have spent any time on it.

      If you and a bunch of others speak up about particular tickets and explain how much pain it's causing you, that's (in my experience) a pretty good way of motivating the people who want to see Elgg succeed. Better would be to fix the issue yourself (I know you're capable!). But otherwise putting a lot of time into "prioritizing" is just not that valuable. Only blockers change releases, so that's all we're putting on milestones so we make sure those don't get drowned out in the noise. 

      /rant

      @Pawel

      vendor/vendors -- my opinion right now is that any package manager would be better than none.

       

    Paweł Sroka

    Former Core Elgg team member, freelance developer.

    Latest comments