I'm posting this issue at the suggestion of greggles, after many people with path_redirect installed ran into problems when the recommended version was updated from beta5 to beta6 and complained. The complained made was that though beta6 was very much a beta, part of the development process not intended to be applied to production sites (on which it broke path_redirect by changing the database tables), Drupal's update system strongly gave average users the impression they should update, without any warning. You know the drill - urgings to do so on every admin page, saying 'You should update'.

Personally, I'm not clear that this *is* a problem with Drupal's update system, or at least not one that can be easily fixed. Nonetheless if people decide some change is appropriate (or whatever the appropriate decision mechanism is - I'm new to this :) I'd be happy to contribute something with a little guidance, if only to show that those complaining weren't all unwilling to do anything else! I suppose at the least the text atop /admin/reports/updates could urge checking/testing before you upgrade betas. Another option would be to modify the warning/colour coding if a new release has 'beta' in its version, though I'm not sure how.

Original issue: http://drupal.org/node/647812

Comments

dww’s picture

dww
we/he/they
commented

Update status/manager never recommends people upgrade to a new beta unless that's the *only* release available on branch. Once 6.x-1.0 is out, we'd never recommend people upgrade to 6.x-1.1-beta1, only 6.x-1.1 when that's out (something that seems to have people bent out of shape over at #647428: Show latest prerelease (if different from recommended release) with dev releases). I'm not sure what else we can do in this situation. If people are already on a beta and a newer beta is out, I don't see how/why we should give project maintainers a way to say "well, it's newer, but you really don't want to be using this, anyway."

I'm extremely tempted to mark this "by design". I'm at a loss to suggest any alternative to how it works now. If someone can provide a concrete suggestion, both for Update status/manager and the UI on project nodes, I'd be willing to listen, but at this point "Dear Dave Reid, please release a beta7 that works better" is about the best/only solution to this problem.

hanoii’s picture

hanoii
Primary language Spanish
Location 🇦🇷UTC-3
commented

My only thought so far about this is why to release a new beta that was not meant for production use. In my opinion, the idea of releasing a beta is very similar to releasing a new stable release. The idea of the beta is just to give the interested user a chance to try the latest additions to the module, and make him aware that here might be room for some bugs, but never release a beta that knowingly will break any current site (that's for the maintainer point of view).

In terms of UI, I guess that it should be easy to have the extras available in the download page and have the update status UI to let the user know that there is a new beta but may be keep the recommended to the latest stable one.

Not sure if this will really make some people (ideally more than the ones who dare use the -dev snapshots) go ahead and try the beta if it's not a recommended one, but it might. If maintainers really want to force users download a new release, they can always release a new version of the module. But this alpha-beta things gives a nice middle release between a stable and a dev snapshot.

Tom Ash’s picture

Tom Ash commented

I understand, you may be right.

Tom Ash’s picture

Tom Ash commented
Status: Active » Closed (works as designed)

There doesn't seem to have been much interest in this so I've marked it 'by design' as suggested.