[#5201] - Add Minimum Stability feature in Joomla! Extensions Update
- Closed
- 3 Dec 2014
- Medium
- Build: staging
- # 5201
- Diff
- nikosdion:feature/jupdate-stability
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Executive summary
Joomla! extensions updater (Extensions Manager, Update) does not understand the difference between stable and testing releases. Moreover, it doesn't really allow developers to have two separate update sources for stable and development builds which can both provide updates to interested users (only the first available update site will be used at any time). This leads to one of two problems:
- If the developer doesn't provide development builds in the main update stream interested users do not get notified about development (alpha, beta, release candidate) builds of extensions and cannot test them, which leads to quality assurance issues for extension developers.
- If the developer does provide development builds in the main update stream unsuspecting users will inadvertently install them, possibly compromising the stability of their web site.
The solution is to allow the users to select the minimum stability of the updates they want to see on their sites, defaulting this to Stable versions only. This PR introduces this feature to Joomla!.
Testing the minimum stability patch for extension updates
Preparation
- Install the dummy test component from http://akeebatest.s3.amazonaws.com/dummy/com_dummy-1.0.0.zip
Confirm the behaviour before the patch
- Go to Extensions, Extension Manager, Update
- Click on Purge. Then click on Find Updates.
- The latest version displayed is 1.2.0.a1 (that's the release marked as alpha in the update stream)
This is a problem because Joomla! proposes an alpha release for installation which is probably not what the average user wants.
Confirm the fix after the patch
- Install the patch
- Go to Extensions, Extension Manager, Update
- Click on Options
- Under the Preferences tab confirm that the Minimum stability is set to Stable
- Click on Cancel
- You are back to Extensions, Extension Manager, Update
- Click on Purge. Then click on Find Updates.
- The latest version displayed is 1.1.0 (that's the release marked as stable in the update stream)
This makes sure that the average user won't be bothered with unstable releases.
Confirm that unstable releases can be shown if so required
- Go to Extensions, Extension Manager, Update
- Click on Options
- Under the Preferences tab set the Minimum stability to Alpha
- Click on Save & Close
- You are back to Extensions, Extension Manager, Update
- Click on Purge. Then click on Find Updates.
- The latest version displayed is 1.2.0.a1 (that's the release marked as alpha in the update stream)
Notes
Your test site needs to be able to access http://akeebatest.s3.amazonaws.com (that's an Amazon S3 bucket). Otherwise you'll get a warning that the update cannot be retrieved and the Update Site will be disabled automatically by Joomla!. If you have this issue and fix it remember to go to Extension Manager, Update Sites and re-enable the update site for the Dummy Component.
After the test you can safely uninstall the Dummy Component.
YOu can also test the installation of Dummy Component updates. You can always see which version of the Dummy Component is currently installed by going to Components, Dummy Component. The version will be displayed on your page.
Known issues (unrelated to this PR)
Extensions using the Collection extension type may experience some weirdness which was already present in previous versions of the Joomla! CMS. Namely, if you have different versions of the same extension with the same target platform only the first version listed in the Collection will be shown in Extensions Manager, Update. This also applies to versions with a different stability.
Moreover, there's another potential source of confusion. A Collection defines several extension records, each one with a version. The extension record may be pointing to a regular update XML file which contains more than one different versions, each one with its own stability. Due to the way JUpdater has always been working only the version defined in the extension record of the Collection XML file will be displayed in the Extensions Manager, Update page. THIS MAY NOT BE THE VERSION WHICH WILL BE INSTALLED.
These issues have been present BEFORE applying this PR, therefore I consider them outside the scope of this PR. The only reason I am mentioning them is that they could be considered UX bugs. I want to make clear that they were pre-existing issues and outside the scope of this PR so please don't ask me to fix them – at least not yet :)
Backwards compatibility
This PR is fully backwards compatible.
Translation impact
This PR introduces seven (7) new language strings in the en-GB.com_installer.ini file. The translation impact is 4 minutes.
Documentation impact
There is the need to add documentation for end users and developers
End user documentation
See Extensions Extension Manager Update
Currently the Options are not documented. If you add documentation for the Options you need to document the new Minimum Stability option.
The Minimum Stability option defines the minimum stability level of the updates Joomla! will propose you to install. By default this is set to Stable which means that only updates marked as stable (production quality) will be proposed for installation. The available stability levels are:
- Development. Unstable, work-in-progress builds. These are usually provided by developers to let you test new features or bug fixes but are extremely likely to break your site.
- Alpha. Early versions of extensions with missing features and a very high chance of major, show-stopper bugs. These versions are very likely to break your site.
- Beta. Versions of extensions in late development stages, where all features have been implemented. Some minor bugs are almost certainly present and there's a small chance of show-stopper bugs as well. These versions are not very likely to break your site.
- Release Candidate. Nearly finished versions of extensions, with the chance of minor issues. These versions are not likely to break your site.
- Stable. Production quality code. This is the recommended setting; stable versions are unlikely to break your site.
Please note that not all extensions provide versions other than Stable on their update servers. You may have to visit the extension developer's site to get access to less stable releases. Finally, not all developers provide stability information on their update servers. If no information is provided, Joomla! will assume that the provided updates are stable. If this is not the case please contact the extension developer.
Developers documentation
See Deploying an Update Server, bookmark Extension. The tags documentation needs to change.
tags. A list of tags relevant to this version. Joomla! 3.4 and later uses this to determine the stability level of the update. The valid tags are:
- dev Development versions, very unstable and pre-alpha (e.g. nightly builds)
- alpha Alpha quality software (features not implemented, show-stopper bugs)
- beta Beta quality software (all features implemented, show-stopper bugs possible, minor bugs almost certain)
- rc Release Candidate quality software (no show-stopper bugs, minor bugs may still be present)
- stable Production quality software All other tags are currently ignored. If you provide more than one tag containing one of the aforementioned stability keywords only the LAST tag will be taken into account. If you do not provide any tags Joomla! will assume it is a stable version.
Votes
jissues-bot
- | Labels |
Added:
?
|
||
Yep, correct. If you have 1.2.0.a1 installed then 1.1.0 is a downgrade so it shouldn't be shown, exactly as you observed :)
@nikosdion It's failing on codestyle
FILE: ...build/joomla/joomla-cms/libraries/joomla/updater/adapters/extension.php
FOUND 1 ERROR(S) AFFECTING 1 LINE(S)
345 | ERROR | Missing @return tag in function comment
FILE: ...home/travis/build/joomla/joomla-cms/libraries/joomla/updater/update.php
FOUND 2 ERROR(S) AFFECTING 2 LINE(S)
400 | ERROR | Doc comment for "$minimum_stability" missing
457 | ERROR | Missing @return tag in function comment
@test all good here. also tested with akeeba backup rc
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5201.
rtc
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5201.
| Status | Pending | ⇒ | Ready to Commit |
tested here. working great. Same result as Ron.
@nikosdion Just a smal one any reason to delete: administrator/manifests/packages/pkg_weblinks.xml?
No particular reason. It seems that the file was deleted automatically when I fetched the updates for the first time, before writing the code of the PR.
So how do we move this into 3.4?
Let me know if you want me to add back the missing XML file. Then we can set it RTC.
I don't understand why such a feature should be established in Joomla core. "Normal Joomla users" should only install stable versions and shouldn't be able to switch globally to "dangerous versions" and forget that they've switched. For me this looks like another Akeeba feature in Joomla core that only some developers need. And these ones should be able to publish a 3rd-party plugin for interested people. Again: I think this feature is dangerous.
I think this feature will allow interest users to improve the quality of extensions, good job Nicholas.
+1 of including it in 3.4
I won't comment on the personal attack, I'll just present the very practical thinking that led to this PR for the benefit of Joomla! up and foremost. Remember that I already have an alternative updater which works much better to fall back to, code I've been developing since Joomla! 1.0 i.e. very long before Joomla! even dreamed of extension updates. I just want to fix the Update package for benefit of Joomla! itself because I have the experience and I can see a major issue in Joomla!'s very near future (6 to 12 months). What issue, you say? I'm glad you asked.
Without the PR Joomla! will propose any update to any user. Since we're moving our core components into separately distributed packages it is only reasonable that we will need to publish development builds, just like we do with the Joomla! core itself.
The Joomla! core caters for the need of out-of-regular-update-stream dev releases (alphas, betas) by providing alternate update channels for LTS, STS and dev builds. Since Joomla! only allows ONE (1) update channel to provide update information at any given time for any extension –including extension 700 which is Joomla! itself– the Joomla! Update component (also written in very large part by yorus truly, for what it's worth) changes the contents of the #__update_sites table directly, purges the update cache and retries fetching the updates.
Quite obviously we cannot implement this feature for each and every core component since it would make alpha / beta testing unmanageable for everyone except the most determined tester. No testers mean the product quality WILL suffer. Moreover, this feature is tied with the schema of the CMS. If the schema changes because Joomla! was updated before the components then the update channel switch code will fail.
For the same reason we can't be in a sane state of mind asking 3PDs to implement a similarly wobbly feature in their own code to let users switch from stable to dev builds. Wobbly features lead to bad user experience which have already earned Joomla! a bad name as being difficult to use and unstable. I'm trying to fix that bad reputation, one small feature at a time, just like everyone else who volunteer their time, expertise and effort for the common good. So, can you please stop confusing me with my company and realise that we're all working towards the same common goal of making Joomla! a top notch CMS built with the future in mind? Pretty please?
Speaking of changing update streams, there's another bug in JInstaller regarding update streams not being updated after installing a new version of an extension with a different update stream location in the XML manifest but I'll fix it later.
pkg_weblinks.xml has to be added back I guess as it is only deleted in case of absence of com_weblinks. (See script.php lines 1181+ )
My test show here that we have to Purge first as otherwise it kept showing the alpha pack on an existing site.
Thanks nicholas for the elegant explanation. I agree with Robert, +1 for
3.4.
Cheers,
Victor Drover
Founder and CEO, Anything Digital LLC https://mail.google.com/ (BBB
Accredited
http://www.bbb.org/milwaukee/business-reviews/computer-software-publishers-and-developers/anything-digital-llc-in-sussex-wi-1000009940/
)
Co-founder, Watchful.li https://watchful.li/ & jInbound.com
http://jinbound.com/
262-309-4140
Facebook: AnythingDigital https://www.facebook.com/AnythingDigital |
watchfulli https://www.facebook.com/watchfulli | JInbound
https://www.facebook.com/JInbound
Twitter: @AnythingDig https://twitter.com/AnythingDig | @watchfulli
https://twitter.com/watchfulli | @JoomlaInbound
https://twitter.com/joomlainbound
On Wed, Nov 26, 2014 at 2:56 AM, infograf768 notifications@github.com
wrote:
pkg_weblinks.xml has to be added back I guess as it is only deleted in
case of absence of com_weblinks. (See script.php lines 1181+ )My test show here that we have to Purge first as otherwise it kept showing
the alpha pack on an existing site.—
Reply to this email directly or view it on GitHub
#5201 (comment).
I totally Agree with Nick here, +1 for 3.4
+1
About time Joomla looses the attitude of babysitting a Super User!
Consider it a perfect balance between protecting dummy webmasters from hurting themselves and allowing Super Users doing their job!
+1
I am using Joomla! as a graphic designer this awesome CMS have helped me a lot!, i am not a coder as many of you here, that is why i certainly will say +1 to this.
+1
This is not a popularity contest. This is already flagged ready to commit.
There is no need to +1 or -1 or to campaign on social media
On 26 Nov 2014 18:31, "Linkedla" notifications@github.com wrote:
I am using Joomla! as a graphic designer this awesome CMS have helped me a
lot!, i am not a coder as many of you here, that is why i certainly will
say +1 to this.
+1—
Reply to this email directly or view it on GitHub
#5201 (comment).
Maybe someone can add the RTC label here to make that clear!
Maybe someone can add the RTC label here to make that clear!
The point of truth is JIssues. It doesn't matter much if there is a RTC label here or not.
I agree that this would be nice to have in 3.4. But at this point in the release process (after alpha and close to beta) it's the call of our release leader @dbhurley if he wants to merge that in.
Thanks.
By the way sorry @nikosdion for hijacking your PR and of course congrats on the idea and the fine code.
I agree that this would be nice to have in 3.4. But at this point in the release process (after alpha and close to beta) it's the call of our release leader @dbhurley if he wants to merge that in.
@dbhurley please make sure that @nikosdion had the time to add the administrator/manifests/packages/pkg_weblinks.xml back bevore we merge this. 
@brianteeman this is a new feature and needs to be approved by PLT. Feedback is a good way to know if people finds it interesting.
I like the idea but I have sent a PR against your branch to convert the stability values into constants: nikosdion#1
thats why we have "Importance of issue to me"
On 26 November 2014 at 20:44, Roberto Segura notifications@github.com
wrote:
@brianteeman https://github.com/brianteeman this is a new feature and
needs to be approved by PLT. Feedback is a good way to know if people finds
it interesting.I like the idea but I have sent a PR against your branch to convert the
stability values into constants: nikosdion#1
nikosdion#1—
Reply to this email directly or view it on GitHub
#5201 (comment).
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
TobsBobs
- | Labels |
Added:
?
|
||
Thank you @phproberto for the PR. I agree and I merged it. Now this PR is ready to rock'n'roll.
Giving it a last review I saw that I forgot to replace some values with constants 
nikosdion#2
| Labels |
Added:
?
Removed: ? |
||
| Labels |
Added:
?
|
||
| Labels |
Added:
?
|
||
Taking off RTC until Roberto's pull is considered
Merged. Please set back to RTC.
Looks like it is done. :)
Merged into staging. Thanks!
| Status | Ready to Commit | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-12-03 08:02:25 |
Added Nic's given documentation into http://docs.joomla.org/Deploying_an_Update_Server#Extension as needed - Hope it looks ok!
Thank you both :)
| Labels |
Removed:
?
|
||
joomla-cms-bot
- | Labels |
Added:
?
|
||
All test described above resulted in expected outcomes successfully
Without patch detected 1.2.0.a1
Detected stable 1.1.0 when set to stable which was set as default after patch was applied, Detected 1.2.0.a1 when set to Alpha
Installation of 1.1.0 and 1.2.0.a1 also tested successfully, reverting to stable after installing 1.2.0.a1 does not sho 1.1.0 (as expecte I assume since you would not want to roll back with the update manager).