Compare http://drupal.org/project/mopa, and http://drupal.org/project/nodewords; in the first case, the beta release is shown, while in the second case alpha e beta releases are not shown.

Comments

apaderno’s picture

Project: Drupal.org site moderators » Project
Version: » 6.x-1.x-dev
Component: Other » Projects

I am moving the report to the correct issue queue.

dww’s picture

Category: bug » feature
Status: Active » Closed (works as designed)

We don't show beta/alpha if there's an official release from that branch. This is intentional. See #176776-41: GHOP #55: Make release summary table UI look more like update(_status)? report.

dww’s picture

Title: Project releases list doesn't include all releases » Show latest release (if different from recommended release) in the "Other releases" table
Status: Closed (works as designed) » Active

Although, in fairness, I was thinking it'd be nice if for a given branch, if the latest release (including "extra" like a beta) is different from the recommended release (the most recent official release without extra) the latest release showed up in the yellow "Other releases" table, just like the "Also available" entry in the Available updates report. I just wasn't sure of the best way to do this in Views without Yet Another custom views handler, so I didn't open an issue about it. I've certainly written plenty of them, so at one level, what's one more? ;) But, it'd be nice to be able to use less custom code and hacks, or we start to loose the benefit of using Views for all of this, anyway... All that said, I can already see there's going to be a lot of "bug" reports about this, so we can use this issue as the place to discuss this.

The main thing I don't think a lot of project maintainers understand is that their project page is primarily for the benefit of their users. ;) We're not optimizing the UI of this page for the project maintainer, but for people considering using that project. We shouldn't be showing those people alphas and betas by default, at least not without some proper warnings.

apaderno’s picture

I think it would be good if the project page would show the beta, alpha and unstable releases like it is doing now when there is not an official final release.

Most users don't use a development snapshot (which, theoretically could be less than an alpha release; version_compare() orders the versions as dev < alpha < beta < rc < pl), and in some projects the update from development snapshot to development snapshot of the same branch is not supported.
I agree that the user should receive at least a warning about the version being still an alpha, beta release, and that those release should be marked differently from the stable releases (as the module is already doing), but I also think that most users look only at the project page, and they don't see there are other version they could at least try.

The module could show the unstable releases when some conditions are verified, or it could allow the maintainers to decide whenever to show an unstable release in the project page (in the same way the maintainers can decide if the development snapshot must appear in the front page).

dww’s picture

Re: "I think it would be good if the project page would show the beta, alpha and unstable releases like it is doing now when there is not an official final release."

That's exactly what it does now, for example:

http://drupal.org/project/mopa
http://drupal.org/project/project
...

Re: "Most users don't use a development snapshot (which, theoretically could be less than an alpha release; version_compare() orders the versions as dev < alpha < beta < rc < pl)"

Exactly. That's why those are listed in a completely separate table with red warnings, e.g.:

http://drupal.org/project/views

Re: "The module could show the unstable releases when some conditions are verified, or it could allow the maintainers to decide whenever to show an unstable release in the project page (in the same way the maintainers can decide if the development snapshot must appear in the front page)."

That's a little more work, but yeah, perhaps I could add another checkbox to that admin UI for each branch to control this behavior. The harder part is getting a single views table to use an OR in the WHERE clause -- that's pretty much going to require a custom filter handler just for this. But, at least if we've already got a custom handler, supporting the UI setting won't be that much harder. ;)

apaderno’s picture

Re: "I think it would be good if the project page would show the beta, alpha and unstable releases like it is doing now when there is not an official final release."

That's exactly what it does now, for example:

I apologize for my bad English; I meant that it would be good if the unstable releases would be shown even when there is a stable release. As it is now, version 6.x-1.3-beta5 would not be shown if there is version 6.x-1.2.
Maybe that has been already changes as I see that in the project page for Views the alpha release is shown, while that was not true for Nodewords, where the only visible version was 6.x-1.2, despite the fact version 6.x-1.3-beta5 was the latest developed version. It is also true that for Views the alpha release and the stable release are for two different branches (6.x-3 versus 6.x-2).

dww’s picture

@kiamlaluno: Right, the difference on views is that it's a separate branch (6.x-2.* vs. 6.x-3.*). So, you're asking for exactly what I'm saying we should have in #3. Yes, I'm agreeing that might be nice (although slightly a pain to implement). But, it would be more in line with the "Available updates" UI in update status/manager in core...

apaderno’s picture

@dww: I am sorry again; my previous comment was just to confirm that was the reason I opened this report (although I opened it with the wrong category).

hanoii’s picture

I just got to this issue because of a beta I tried to release (as I did before) was not being displayed. There was quite a discussion about dev, stable, alphas etc back then in the wysiwyg module.

I think the alpha/beta extras on the release are good warnings by itself, and I sometimes a new beta is better and needed over a previous stable release on the same branch, but the -beta gives an idea that some more work might be needed.

Anyway, I guess that for now I'll have to release a new 'stable' release so it shows up in my project's page.

dww’s picture

FYI: see #651894: Messages urging updates lead to problematic beta updates on production sites for why I marked this "by design" in the first place...

Ela’s picture

Subscribing.
I've spent a day updating meta-tags see: http://drupal.org/node/708530 just to see that they are not being saved, and had no idea that beta was released that fixed the problem.
It would really be helpful if we could be notified of such releases :)
It is impossible to check each module's page ...(and then check each module's releases page in addition) if you are using a lot of them.. We simply rely on the update to show / notify us if there is a new version..
Any tips on how to do this for now to not run into problems like that?

sinasalek’s picture

That would be nice if it was optional

sreynen’s picture

I've run into this same problem with 1.3, 2.0 dev, and 1.4 beta releases (created in that order). Sounds like a complex technical problem I shouldn't expect to see solved any time soon.

We shouldn't be showing those people alphas and betas by default, at least not without some proper warnings.

I disagree. We're already showing alphas and betas (along with pretty much every other software project), but only at major versions. Doing the same at minor versions wouldn't cause people to suddenly lose their ability to comprehend the terms "alpha" and "beta."

mikeryan’s picture

Coming from #1098536: Releases block broken on project pages - doesn't show newly published security release.

+1 for showing alphas/betas/etc. of minor versions on the project page as "Other releases". The point (well, at least my point) in releasing a beta is to get some feedback before committing to a stable release, and it's tough to get feedback if the beta release is not visible on the project page.

We're not optimizing the UI of this page for the project maintainer, but for people considering using that project. We shouldn't be showing those people alphas and betas by default, at least not without some proper warnings.

It depends on what people are using the project. In my case (Migrate), the audience is developers - they're both unlikely to be confused by the presence of alpha/beta releases, and to be bolder than other users about trying intermediate releases.

Question - all the talk in here is about alpha/beta, if I made an RC release would it be visible?

Thanks.

dww’s picture

Right, there are reasonable reasons to make these early-adopter releases visible on many projects, provided there are sufficient visual cues that end users don't accidentally download something they're not prepared to handle.

To answer your question: no. ;) Project*, Updates status, and the world at large prefer official releases without any "extra" qualifiers over alpha/beta and even rc releases.

Cheers,
-Derek

msonnabaum’s picture

I recently tagged drush 4.5-rc1 which I would have expected to be able to add to the project page, but it looks like I can't because of the issues outlined here.

It really would be nice to be able to do that since we'd rather people were downloading 4.5-rc1 instead of 4.4. If people can't find it, we're not likely to get much testing out of it.

apaderno’s picture

Dave Cohen’s picture

I'd like user's to download the 3.1 beta of my project. But, because I created a 3.0 release, there's no way for me to communicate that to my users.

Because a 3.0 release exists, the project page will not show the 3.1 beta.

To hide the 6.x-3.0 release, drupal.org hides 6.x-3.x-dev release, which I still want users to use.

And user's get a "this version of the module is no longer supported!!!!!!" message.

(All objectionable behavior, IMHO)

I'd like to see a checkbox on each release form, "show this release on the project page."

I'd like a way to delete releases. If I could delete that damn 3.0 release (the node on d.o, not the code), I wouldn't have that problem. There's no way for me to delete it myself and no one who can has stepped up.

mrf’s picture

One potential downside to the current approach is that it encourages project maintainers to publish untested point releases.

I see projects that have to roll out another point release very quickly after finding a major bug. It would be nice if the only people who were affected by this were people that made the decision to try out a rc branch. The current situation makes the entire user base (who decide to upgrade) one big test group whether they know it or not.

NancyDru’s picture

More than 3 years into this. I still have no way to let users know that there is a release (7.x-1.1-beta1) that needs to be tested because it has significant changes. Update doesn't even show it as "also available." So how are the users supposed to know? This means that the next release is going to be a big shock to them.

sinasalek’s picture

Yup, right now the only way is to either make a new major release or use dev snapshots and put a note on module's page :(

NancyDru’s picture

There will be a dev snapshot at midnight (GMT), but that grabs no one's attention, especially with all the fixes I've been committing lately. I did put a note on the project page. It seemed to take a while, but the beta is finally showing up on the Update list.

jweowu’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev
Issue summary: View changes

Awfully frustrating that there's still no visibility for release candidates on project pages.

I presume this issue needs bumping to 7.x ?

Liam Morland’s picture

mpotter’s picture

OK, I can't believe this still seems to be an issue.

Released an rc1 of the next Open Atrium today (2.30-rc1). But because we have a 2.27 version it will not show the new rc1 release on the project page. Not even when I enable the Show Snapshots option.

So how are people supposed to learn about rc1 releases and test them? Why doesn't the module/distro maintainer have control over this. There should be checkboxes in the Releases section where we can decide which releases we want to show. I don't care what the *default* is set to, but there are good reasons for wanting to push people to an rc release instead of an older "stable" release.

For now I'll manually add text and a link to the rc1 release in the project page just like other modules (Migrate) are doing.

But this is super frustrating!

rudiedirkx’s picture

Yeah, this is kinda ridiculous. There's no way for users to find newer beta/rc releases of the same major. Very weird.

Is there any activity on this..?

helmo’s picture

It would be really nice to show beta/alpha releases in the 'Other releases' section.

markhalliwell’s picture

Component: Projects » Releases
Category: Feature request » Bug report

Why doesn't the module/distro maintainer have control over this. There should be checkboxes in the Releases section where we can decide which releases we want to show.

YES!

I don't care what the *default* is set to, but there are good reasons for wanting to push people to an rc release instead of an older "stable" release.

YES!

---

I have the same issue with Bootstrap. Our "stable" release is actually severely outdated. This is just an unfortunate side-effect of available time to maintain the project.

I'm setting this as a bug because it is actually hurting project management. We have had several beta releases since then (and soon to be an RC).

This really needs to get fixed.

markhalliwell’s picture

Component: Releases » User interface

Actually this is specific to the UI, the releases exist.

John Franklin’s picture

I'd like to propose a different solution. The current set of tables are:

  • Recommended releases
  • Other releases
  • Development releases

To be more consistent with listing releases, I think we should add a fourth block titled something like "Upcoming releases" and put alphas, betas and rc releases that are later than the current Recommended release. If there is *only* an alpha, beta or rc, then no release shows in the Recommended releases and the alpha/beta/rc shows in the Upcoming releases.

This will make things easier for the security team, too. AIUI, the security team does not support alpha/beta/rc releases, only full releases. When engaging with the community, the security team can describe their support policy as "only releases in the green section."

I'm trying to work on a patch for this, but keep running into PDO errors and broken/missing views handlers.

John Franklin’s picture

Is there a pre-built test database available for crafting patches?

rudiedirkx’s picture

@John Franklin I like it. Clear difference between stable and not-yet-stable-but-newer. Would there be a way (or reason?) to create a release but hide it? Currently you can't see 1.6-beta1, but maybe with your table, you can't hide it? I don't know why you would create a release and not show it, but it might be important?

John Franklin’s picture

The "Upcoming Releases" could have checkboxes to show or hide similar to how the Development releases table currently works. That's a reasonable control to add, and would (I think) satisfy @mpotter's request above for "checkboxes in the Releases section where we can decide which releases we want to show."

drumm’s picture

Title: Show latest release (if different from recommended release) in the "Other releases" table » Show latest prerelease (if different from recommended release) with dev releases
Project: Project » Drupal.org customizations
Version: 7.x-2.x-dev » 7.x-3.x-dev
Assigned: Unassigned » drumm
Category: Bug report » Feature request

With the downloads rearrangement from #2688127: Make automated testing results more prominent on project pages, I think we have a better place for this.

Development releases are now next to the recommended release. An additional pre-release makes sense to be nearby.

  • drumm committed 3142173 on 7.x-3.x, dev
    Issue #647428: Show latest prerelease (if different from recommended...
drumm’s picture

This has been deployed. A current example is https://www.drupal.org/project/location.

drumm’s picture

Status: Active » Fixed
jweowu’s picture

Excellent news. Thanks drumm!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.