I maintain a couple or more Drupal installations to help me with testing and my further learning. In order to test most recent features/patches I need to keep only the latest dev versions of modules installed. It so happens though that once you install a stable release, you are no longer notified about newer dev versions of a module (only newer stable ones). So, what I try to do is ignore the stable releases. In this task Update status advanced settings has helped me a great deal, but I frequently find myself in the situation of having to go to the settings page simply to un-ignore a stable when a new dev is available and then again ignore a subsequent stable and so on.
Can we please have an extra item in the drop-down menu for each module to ignore all its future stable releases? The way it is now only the currently available stable can be ignored and this causes the situation I described earlier.
Thanx in advance.
PS: An alternative to this per-module setting would be a global checkbox (like the 'Check for updates of disabled modules and themes' setting) that would 'hack' the default core behavior so that people are informed of newer dev versions as well. But still the per-module setting would be more useful IMO.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | more-than-one-stable-versions.png | 30.83 KB | klonos |
Comments
Comment #1
klonos+ there is always the occasional case where a module/theme will have two 'stable' releases available, one 'Recommended' and one 'Latest' (usually an alpha or beta or RC). In such cases, you always get update warnings no matter if you ignore the recommended stable release or not.
Comment #2
klonos...actually having thought this through a bit harder, I think we should implement a series of sub-features in order for this to be complete. Please keep in mind that this feature is requested to mainly help module and theme dev/beta testers like myself. Let me know what you think and if I should break these in separate issues.
1. Globally allow dev versions to be reported as available updates if newer ('Also check for available development versions of modules and themes' checkbox).
2. Add extra items in the per-module 'Warn if out of date' drop-down:
- Ignore all stable and recommended releases
This partially covers the issue in #1 (actually it is a side-effect) and the case of people in need to use only dev versions of a couple of specific modules/themes. It basically ignores stable versions if they are newer than dev builds and saves people from the trouble to have to specifically ignore each new stable release as they come out. Don't think this is obsolete if the 'check for available dev versions' feature is actually implemented, since this is a per-module setting as opposed to the global feature. It serves as an exclusion helper when combined with the global setting.
- Ignore latest recommended release
This fully covers the issue in #1 when one wishes to use the latest stable release instead of the recommended (in the case the former is newer). I am aware that this would cause people using a beta to not be informed of a newer beta or even a RC, but why would they set this in the first place if so? I mean they can always use a dev or the stable. Right? Correct me if I am missing something.
- Ignore development versions
This covers the case where one wishes to get update notifications of dev versions in general (global setting enabled), but wants to exclude one or two known-to-have-issues dev builds of certain modules/themes.
- Ignore dev version by date/checksum
This is required in cases where newer dev versions come out, but they are known to break things. Currently the only way to tell dev versions of the same branch apart is by their release date (they have the same versioning format, like 6.x-dev). This exclusion selection would allow one to be able to use a previous dev (you do keep backups, don't you?) skipping the current one that has known issues, but still allow them to be informed of the next dev (that hopefully fixes things). I was thinking that the 'notes' field could serve as the date argument field to start with, but there might be a better way. We need to remember that sometimes there are more than one dev built within the same date. So we'll either need to check date + time or exclude builds based on their md5 checksum.
Thanx for taking the time to read all this.
Comment #3
lpalgarvio commentednice thinking here
Comment #4
bibo commentedsubscribing. Waiting on this stuff and for the D7 release :)
Comment #5
izmeez commentedsubscribing
@klonos re: comment #2
I like item #1. This could even be of use to newbies to show when dev versions are available and actively undergoing change.
item #2 is a bit complicated and could help with the multitude of other cases; although the fourth item might be quite handy.
Comment #6
Leeteq commentedYes, this is important.
One of the biggest annoyances of the update_manager in core is that on the update page, where we select which modules to be updated, we simply _cannot_ choose to upgrade an old -dev version to a newer -dev version, if there is another "recommended" version even if that version is _older_ than the currently installed -dev. This makes absolutely no sense, and should be provided by this module, IMO.
So big +1 to the main suggestion here (#1), and also in favor of the other options suggested in #2, point 2.
It would be nice if #1 could be fixed and committed without being held back by #2.
That one is almost "critical".
Comment #7
klonosPriority levels of issues:
I know, we all *need* this, but it doesn't break functionality the way it is now (not for regular users at least - our use cases seem to be a bit edge ones since we use dev versions and all). It would be "nice to have", so definitely not "major".
Besides...
- the project's maintenance status is "Seeking co-maintainer(s)" and its development status "Maintenance fixes only",
- Dave and Derek (the project's maintainers) have not made any commits for 2 years in this project's code,
- if any of you were following #454368: Port update_advanced module to D7, you already know that even the port to D7 was (mostly) done by Pasqualle and while I suggested that he became a (co-)maintainer, he also seems to be pretty busy and kindly declined.
- Ilmari (bibo) offered and applied to co-maintain the 7.x branch too (#1419074: Co-maintainer Application for update_advanced), but as you can see that is postponed :/
...what I'm trying to say is that I guess we won't see any action here soon. If a new maintainer is found, I'll give this issue a proper summary and/or even split it to separate smaller issues.
Comment #8
bibo commentedSorry for being slow to respond. My saying "when I have time" in that other issue was pretty vague, especially because I rarely seem to have time for anything.
This would be a good case to show that I'm not entirely useless though ;) I should have "some time" at the end of may. I can't make a promise though, but there is a 52.6% chance I could and would look into this and propose a batch. If waiting is out of the question, sorry :(
Comment #9
hass commentedThis issue is now sooo old that it seems to be solved by time. Can someone confirm if we can close this case now?
Comment #10
klonos...far from solved.
This feature request here is closely related to #745816: Offer dev versions as updates (if they are newer) even if a stable release is installed (actually that issue would be a sub-task of this one here) and is in fact point 1. in comment #2 above.
People that want this to happen seem to agree that we should do that first, since point 2. (the "fine-grained control over ignored items" part) is more complicated and estimated to take more time to implement its logic.
@hass: So, Alexander please feel free to ask me to clarify any part that might not be clear or make sense to you. Thanx in advance.