turn off beta notifications?

I thought about that. 'beta' isn't really an officially recognized setting, it's just something a developer puts in the 'extra' field.

That said, there's a couple of options.

1) pick everything we can think of that might apply as beta, and check the version string for it. The obvious ones are 'alpha', 'beta' and 'rc'.

2) assume anything with an 'extra' item is of the 'beta' variety. I don't like that and it's actually a little difficult for us because we don't get the version numbers broken down. 1 is easier and probably better, though it means we could miss non-standard beta types.

Does anyone else have thoughts?

we could have an advanced setting for the admin to specify the regexp of version strings to ignore. ;) the default would be something like:

.*(alpha|beta|rc).*

but site admins could tweak their own ignore policy this way... don't tar and feather me -- i'm just brain storming. ;)

we could also change the XML-RPC protocol to return the version info as an array instead of a string. we already have to change the protocol, anyway: http://drupal.org/node/136172

btw: here's an example of why turning off notifications for any release with "extra" is a bad idea: http://groups.drupal.org/node/3629#comment-10717 -- that's why i'd be in favor of the regexp that targets alpha|beta|rc, instead of anything with extra...

Instead of looking at beta, how about showing dates of all releases?

As the current version works, it shows the release date of the available module, but not of the currently installed module -- if the date of the currently installed module is more recent (ie, someone grabbed a stable dev/beta release because they have faith in the module maintainer) --

For example, I'm running the latest dev tarball of 5.x, and the module is telling me that my version on Drupal is out of date. However, I have the latest build as of early April, where the 5.1 tarball was generated in January

The problem is that we don't know the release date of the currently installed module.

http://drupal.org/node/136172 is basically done, and merlin and i are hard at work on a 5.x-2.0 release of update_status that fixes a bunch of problems, including this one. my current theory is as follows...

when we're reading through the release history for a given module and comparing that with what we're currently running, we do the following to decide if we should flag the site as out of date. as soon as we find an answer, we stop looking:

1. check if the default major version listed in <default_major> is newer than what we're currently running. if so, find the release with the new default major with the highest patch level and nothing in the <version_extra> tag (where "beta1", "rc3", etc, etc, all live), and use that.
2. find the release with the highest patch level and no extra. if that patch level is higher than what we have, use that.
3. find the release with the same patch level and the newest date, even if it has extra. if that's different than what we're running, use that.
4. otherwise, we're up to date, so return false.

so, in general, update_status won't bother you about a release with extra in it. however, if you're running a given patch level (e.g. views 5.x-1.6-beta2 is patch level "6"), and another release comes out with the same patch level, but a newer date (e.g. 5.x-1.6-beta3), your site would bother you about needing to upgrade. however, if your site was still running 5.x-1.5 (official), it would leave you alone until the official 5.x-1.6 came out. also, if you were running 5.x-1.6 official, and then a few days later, 5.x-1.6-2 comes out (e.g. for those crazy maintainers who notice a bug and prefer this over just making the 5.x-1.7 release), it'd also warn you.

the only case this doesn't quite solve in the cleanest possible way is this:
- site running 5.x-1.5
- maintainer releases 5.x-1.6
- maintainer release 5.x-1.6-oops1
- site checks update status
that this point, it'll tell you to upgrade to 5.x-1.6, when in theory, it should tell you about 5.x-1.6-oops1, instead. so, we could modify rule #2 in the above algorithm so that after it finds another official release (no extra) with a higher patch level, it should basically apply rule #3 immediately and see if there's another release at that patch level with a newer date, and if so, use that.

alternatively, we could leave the algorithm simple, and in this worst-case scenario, after you upgrade to 5.x-1.6, it'll just warn you again that you need 5.x-1.6-oops1. or, better yet, we just train module maintainers to make that 5.x-1.7 instead of 5.x-1.6-oops1. ;)

the current code in HEAD tries to do this, but is still a little buggy. stay tuned.

for clarification, here's a screenshot displaying the bugs i was talking about.

1. project_issue 5.x-0.2-beta is a security update, so it should be getting flagged as such.
2. both project and project_issue have an empty/bogus "recommended version" (possibly because there's no "clean" release of either one... the only 5.x-compatible releases at this point are still betas).
3. the display for views needs some spacing between the end of the date of "latest version" and the "Download" link.

I tend to agree that if you're tracking beta releases (as you would be while your site's under development), it makes sense to recommend updating to a higher beta release. For sites tracking stable versions, they only get notified when there's a new stable release.

after further debate in IRC, we all decided that the current behavior in the code is exactly what we want. even if you're already tracking a beta release, update_status should never recommend another beta. it always recommends the latest official (no-extra) release from the current default_major branch. if there's a newer release on the same branch, it'll list that as "Latest:" but not recommended. as clouseau (aka jvandyk) wrote on IRC:

just because you're running a bleeding edge beta doesn't mean the next broken beta is recommended; the last stable release is still recommended

good advice. ;) therefore this is now fixed. however, this whole topic brought up the question about how to handle release from different major versions. so, see http://drupal.org/node/149918 about adding some "Also available:" entries to the status report.