Elgg Releasing Too Fast

I feel like Elgg community has started to release elgg versions too fast where some of the plugins are just still sitting in elgg 1.9 version while many are still in 1.8. I feel like you guys give some time for the plugin developers to bring these plugins to the released update version. it's like 3 months back i came to elgg 1.9 & now it's in ellg 1.11 . Well i really appreciate the elgg team hard work & improvements they are doing but they need to also find the balance side of the community plugin development which has started to stagnant.

Does any of you feel's like me ? 

  • I feel the opposite, it's great that they're releasing new features and enhancement.

  • I think you're assuming plugins written for 1.9 need updates to work with 1.11. They don't.

  • Which is fantastic by the way because that means everyone can get the latest work from the Elgg Team right away instead of waiting years between releases!

    If you find any 1.9/1.10 plugins that don't work seamlessly on 1.10/1.11 please do let us know.

  • @Evan: how about this: while it's too late for 1.X (and not possible due to Semver only been introduced with 1.10) there could be a new way to define plugin compatibility for 2.X: simply "compatible with 2.X". Then it's not the burden of the plugin developers or the end-users to test compatibility of all their plugins with the latest release every 3 months but it's Elgg core that might have to get fixed in case any incompatibility turns up for a plugin that worked fine on 2.X but does no longer work on 2.(X+1).

    Personally, I find the 3 month release schedule too tight, too. I could perfectly work with a 6 month release schedule (with monthly bugfix releases instead of the bi-weekly releases). Currently, it's just really a lot of work to update the info for all plugins regarding compatibility when a new release of Elgg is available. And it's even more work if you don't blindly assume that it works on the new release but want to test it (even only briefly). It's just not very end-user / Elgg beginner / non-developer friendly to simply say "it should also work on the new version of Elgg" if it doesn't say so on the plugin release page.

  • I think you're assuming plugins written for 1.9 need any updates to work with 1.11. They don't.

    I would argue this is not completely true until admins stop seeing visible deprecation messages. There's an issue about that: https://github.com/Elgg/Elgg/issues/7946

    there could be a new way to define plugin compatibility for 2.X: simply "compatible with 2.X".

    While plugin made for 2.0 will work in 2.1, we must still be able to define the minimum version. A plugin made for 2.1 doesn't work in 2.0 if it uses a feature that didn't exists until 2.1. Therefore we must still include the other (2.1, 2.2, etc) options.

    The idea itself is good. The compatibility setting could be changed so that under the hood it would mean "This is the minimun required Elgg version. Mark the plugin compatible with future versions automatically."

    And it's even more work if you don't blindly assume that it works on the new release but want to test it (even only briefly).

    Ever since 1.9 I've been just blindly marking them compatible. We haven't removed any public API in the 1.x versions after 1.9. Only deprecated, which doesn't prevent you from using them (if you don't count the visible error message I mentioned earlier).

  • @iionly - I agree. 6 months would be fine. The problem is not so much <1.11 plugins not working in 1.11 as 1.11 plugins not working in <1.11. It really dilutes the plugin pool for those of us stuck on earlier versions, especially as keen developers quite understandably tend to release fixes for newer versions and leave the older ones be. Or, if they are dabblers like me that have odd times available periodically, release plugins for versions that are several behind the current one because they do not have the resources to upgrade. Either way, it balkanizes the whole thing. There are currently at least 5 not fully compatible versions of Elgg (not counting <1.7, of which there are no doubt a few) running on production systems with many thousands of users and, by the end of year, there will be 7 or more. This dilutes rather than strengthens Elgg.

    With the best will in the world but minimal resources to work with, we at Athabasca U are still struggling to hit an August deadline to upgrade from 1.8 to 1.9, about 18 months after we started the planning process. I had almost settled on moving to 1.10 and now am wrestling with whether to go straight to 1.11 or beyond. But the further it moves, the trickier that becomes: simply moving through the minor upgrades on a live site is a pain when you have more than one to consider and any downtime is a bad thing. I think it is really important to remember that many of us avid fans of Elgg are simply unable to dedicate a lot of time to it and we have a great many plugins on which we depend, along with thousands of users to worry about, a mass of path dependencies, and testing cycles that alone take many weeks. On a three-month cycle we might, if we really pushed hard and had minimal work to do on existing plugins, have nearly enough time to implement a new minor upgrade by about the same time the next version is released. But we would be spending a lot of time running to stay in the same place whereas we want to be improving what we have. Core Elgg is great and I am delighted with the work being put into it, but it is not really what the system is about -  the whole point of the framework architecture is the plugins, and it takes a long time for these to fall into line. 

  • I agree to slow down the release cycle. I really tried to move to 1.9 for my high volume production sites, it was impossible since a lot of plugins are still lacking behind. It took me weeks of testing, adapting and finally had to throw the towel in the ring.

    So I am still stuck to 1.8 for serious production sites for a while, but if the release schedule continues with this speed, more plugin developers are getting caught up with testing and BC. It seems like a race never to win, since core has already released a new version with new BC issues.

  • This is one of the reason why I stayed away from relying on other people's plugins because once a major release comes out, I don't have to worry. The theme and other plugins on my site are made by me so I can just update it without a problem.

  • composer feels like the answer to this. It will give you the latest and greatest packages that match your version constraints without having to run around and check each plugin page manually.

    Weeks of testing? How much automation do you have? That certainly sounds like far too much effort just to upgrade... :(

  • core has already released a new version with new BC issues.

    This is just fud unless you have specifics.

Performance and Scalability

Performance and Scalability

If you've got a need for speed, this group is for you.