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 ? 

  • Thanks Evan - it takes so long because of 1) over-bureaucratic and under-funded systems that can mean a simple 2 minute update of the testing server from our SVN repo can literally take weeks to get done and 2) the fact that there are just two of us with extremely full-time jobs testing in our spare time - averages out at a few minutes a week each. We've got some automated testing using Selenium running in Firefox but it only covers the basics and, of course, we have to test in multiple browsers and platforms, especially for big changes like themes and minor version changes, or where changes affect many things. I have willing students, but we hide our test servers behind an impenetrable VPN to which they have no access. Frustrating, but it comes with the territory of working in a rigidly hierarchical and highly traditional academic IT environment :-( On the bright side, I've got a little research funding to put into speeding up the updating process that should kick in soon, but it's a slow, slow system even then.

    I've not come across Composer before, thanks - reading the docs now. 

    We have till now been using iionly's very useful Elgg Update Services plugin to help stay on top of plugin updates. Though it is a little hit-or-miss at times, it certainly saves a lot of time for routine updates. It would save even more if it could put the plugins directly in the mod directory.  I'm quite fond of the way Wordpress handles this kind of thing - very intuitive and controllable. Crossing over topics to the thread on the future of the community plugin repository, it would be awfully cool if Elgg could do something similar natively. I don't think it would be a great idea to update the core or plugins in situ on the live site as is common on Wordpress sites, but it would certainly make updating test sites much easier. 

  • If you consider that the semantic versioning kicked in once we released 1.9, not much has changed other than the numbering and the frequency of small releases.  It's just that we've been releasing versions with features as the minor release since that change, whereas before they were point releases.

    To put it in other terms Elgg 1.11.0 is what would previously be known as Elgg 1.9.13 on the old versioning system.  The upgrade path is the same.  There was a back compatibility break between 1.8 and 1.9, so upgrading plugins between those versions will be a bit more intensive (though nothing compared to the 1.7 -> 1.8 effort), but 1.9 through 1.11 should require no changes.  Any changes that may be required will be very minor, and we're encouraging people to report issues of back compatibility.

     

  • I want to echo @jondron's sentiments. In corporate worlds--especially "East Coast Corporate"--3 months is way too fast. At work we've been in the process of upgrading from 1.8 to 1.9 for nearly 6 months. This is a team of 3 engineers, a project manager with some coding skills, and a QA guy.

    For us, it's not just upgrading plugins, but also the overhead of having to vet the code, having to get approval for a new version, having to test the new version in multiple environments, etc. An extreme example of this is we are currently in transition to the 2011 version of Office 365. In our case, the solution is to upgrade to 1.9, then upgrade to 1.11 (skipping 1.10) hopefully more quickly.

    We've discussed the release cycle before and came to the decision that shorter release cycles means fewer changes to core per release, so theoretically makes it less of a pain to upgrade. 1.11 is only the 3rd release on this cycle; this has only been happening for 6 months, so we're only just seeing growing pains now.

  • Another idea I had was to just not announce releases anymore. We would keep announcements for only issues we think are truly noteworthy. Perhaps that would cut down on the psychological stress of "falling behind"

  • It was a pain to get from 1.8 to 1.9, but after that if the plugins have been checked on 1.9 you can most likely blindly update to 1.10/1.11

    We did this with some clients. We tested a long time on 1.9 (1 month) but then upgraded to 1.10 in 1 day ;)

    Yay for semver!!!!

  • @Evan "This is just fud unless you have specifics." I don't know what fud is, nor does google translate but I can guess :-)

    There is a 1.10 deprecated file https://github.com/Elgg/Elgg/blob/master/engine/lib/deprecated-1.10.php so there are BC issues in 1.10 for sure but not many I see. Though, from what I remember I had a lot more red notices when upgrading from 1.9 to 1.10.  Don't know why anymore.

    I see there is no 1.11 deprecated file so 1.10 to 1.11 you are right about that. As to testing, I have not automated testing, never needed that since 1.8 was there over 2 years. Any suggestions ?

    I do have the code analyser plugin from Pawel Sroka, which is very helpfull.

    Can anyone explain how composer can help verifying plugins ?

    [Moderator: this comment was off-topic. It was moved to its own topic.]

  • FUD = Fear, Uncertainty and Doubt http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

    Something getting added to a file named engine/lib/deprecated-x.x.php does not mean you should immediately stop using those functions. It simply means they will be removed sometime in the future. Until that you can safely continue using them.

    As I said earlier, the misconception about plugin incompatibility is caused mainly by the visible deprecation errors that are being displayed to the admin users. Adding that feature was a mistake from out part - we shouldn't expect admin to be the same person who is responsible for installing/upgrading/developing plugins. Therefore those messages should not be displayed to admin by default.

  • I have to admit, that allthough I am intensely using Elgg, from developer  admin and user perspective, I still miss a lot of what you guys are doing and why.

     

     

  • Unfortunately things do break. Though nothing major, they still require attention and time.

    For instance, I have discovered today after upgrading a site to 1.11, that likes plugin now uses new js toggles, which resulted in duplicate click handlers (one from core and one from a plugin), as a result clicking like creates a double annotation.

  • That information does not belong to this discussion, but into the issue tracker.

    If we have mistakenly made a breaking change in 1.11.0, that change should be reverted so that your plugin works correctly again in the coming 1.11.1 release.

Performance and Scalability

Performance and Scalability

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