in the UI discussion around how to handle beta releases and other special cases over at http://drupal.org/node/136525, we came upon the discovery that just having "Recommended" and "Latest" isn't sufficient. use case:
you're currently running views 5.x-1.6-beta2. 5.x-1.5 is the last official release without extra. 5.x-1.6-beta4 is now out, as is 5.x-2.0-beta1, a beta release of a whole new release series for a different feature set. what should update_status tell you?
our current proposal:
Views 5.x-1.6-beta2 [your current version, what it tells you already]
Recommended version: 5.x-1.5
Latest for same major version: 5.x-1.6-beta4
Also available: 5.x-2.0-beta1
we'd probably put the "Recommended version" in bold (see http://drupal.org/node/149079).
exact wording for "Latest ..." is to-be-decided, but something like the above.
Also, in weird cases, there might be multiple "Also available" entries, like if there are 5.x-1.*, 5.x-2.* and 5.x-3.* release series available.
The basic algorithm:
1) recommended is the latest official (no-extra) release from either a) your currently installed major version or the default_major version as specified by the project maintainer, whichever is greater.
2) latest is what it says: the latest official release (even with extra) from the same major version we're tracking.
3) Also available lists the latest official release (even with extra) from any other major version(s) that exist which you're not running yet.
so, this *does* introduce the idea that this module would recommend different things to different sites in the case that the currently recommended major version is 1, one site (A) is running 5.x-1.*, but another site (B) is running 5.x-2.*. in this case, update_status would tell site A:
Recommend version: 5.x-1.3
Latest release from same branch: 5.x-1.4-beta2
Also available: 5.x-2.2-beta1
while at the same time, update_status would tell site B:
Recommend version: 5.x-2.1
Latest release from same branch: 5.x-2.2-beta1
however, once a site isn't running the default major version, we can't recommend a downgrade, since no module maintainers ever handle the "downgrade" schema migration path, etc. we all feel that recommending different things to different sites isn't necessarily a problem. the thing merlin was rightfully sticking to is that we should never recommend a beta release to anyone, which i now agree with completely.
the 1 open question here is if "Also available" should always show the latest from the other branches, or the latest non-extra release (if one exists). so, in the above example, should it tell site A what i wrote above, or just: Also available: 5.x-2.1 since that's the latest non-extra release from 5.x-2.*? of course, if 5.x-2.0-beta1 is the only release from 5.x-2.*, that's what we'd show. the question is what to do if both 5.x-2.1 and 5.x-2.2-beta2 exist, but not yet 5.x-2.2 official. comments on this detail welcome.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | update_status_recommended_vs_latest.patch.txt | 2.6 KB | dww |
| #3 | update_status_also_avail.patch.txt | 14.28 KB | dww |
Comments
Comment #1
nancydruI'm not sure I would include an older -beta in the "also available" list. But the ones bewteen the version the person has and the latest one, yes. So in this example, I would expect to see Current -beta2, Latest: -beta4, Also available -beta3. It's too bad there's no place in the .info file for signifying a required release to help narrow down the recommended version - for example, AcidFree 5.x requires Views 1.6-beta4 or higher, so recommending 1.5 is misleading, but there's not much that can be done about that.
Comment #2
dwwno, this isn't going to completely replace the listing of all possible releases for each module you have installed. if that's what you want, go to the project node. ;)
we're just talking about notifying users of the existance of the *latest* releases they *might* care about, even if they're not officially-recommended releases. so, we might tell you 5.x-1.6-beta4 is the latest, and that a 5.x-2.0 is also available, but we're not going to also mention 5.x-1.6-beta1, beta2, and beta3. i think we can assume our users are smart enough to figure out that if the latest is beta4, beta3 must also exist, and if they *really* want to run a less-than-current beta, they should have to go out of their way a little bit, click on the link to the project node (which we already include for them) and go find their stale beta.
otherwise, this UI is going to completely overwhelm admins with noise they don't care about, drowning out the signal.
re: version-specific requirements. yeah, we've talked about that a lot in the past. the basic answer is it sounds nice on the surface, but the details really suck and it's too much work without enough pay-off to implement it. core's not going to support it for module dependencies, so neither will update_status.module. that's why we include the links to the release notes... this problem can and will be solved via documentation.
cheers,
-derek
Comment #3
dwwthis is a rather huge patch for a small thing, but it's the fruits of my labor on my flight home from Chicago tonight... ;)
- implements the feature described here
- solves the bugs still lingering with http://drupal.org/node/125742
- fairly major re-write of update_status_calculate_project_data() for (i hope) improved clarity
- massive (perhaps excessive) phpdoc comment added and more comments sprinkled throughout
normally i like to keep things small and self contained, but i felt like a solid re-writing (which i had been meaning to do for a while, anyway) was the best way to get this working cleanly, and fixing #125742 just came out naturally in re-doing this code. the patch itself is really more confusing than the code. in this case, i'd recommend applying the patch and then just reading update_status_calculate_project_data() if you want to review this (there are a small handful of related changes outside of that function at the very top and bottom of the patch, too).
committing this patch is a key step towards the 5.x-2.0 official release, so i'm bumping the prio to critical.
Comment #4
merlinofchaos commentedThe code is clean.
I tested this on my test system and it appears to do everything correctly.
Comment #5
merlinofchaos commentedOne minor note: The 'security update available' text is in a bad place and is obscured.
Comment #6
dwwYay, thanks for the review! Committed to HEAD. Yee haw.
Let's move the discussion of the UI for the security updates back to http://drupal.org/node/125742 where it was added...
Comment #7
dwwwhoops, there's a bug in the logic that shows up in the edge case where you're running the recommended version, but there's a later beta available from the same series. e.g. you're running views 5.x-1.5, but views 5.x-1.6-beta is out -- currently, due to the bug, it actually recommends 5.x-1.6-beta. attached patch fixes ths. it also changes it so that if the latest != recommended, we always print the row for latest, even if we're otherwise up to date...
Comment #8
dwwmerlin committed this to HEAD: http://drupal.org/cvs?commit=70786
Comment #9
(not verified) commented