Skip to main content
Mr_J_Rey
New Participant
January 5, 2016
Answered

Why are beta releases older than production versions?

  • January 5, 2016
  • 1 reply
  • 1991 views

The version currently available through both the beta release direct download & auto-updates is 20.0.0.255 for NPAPI but the production current release version is 20.0.0.267 so why exactly is the comparable beta version number less than the same production release or is everything just out of sync?

Comparing the beta release notes‌ currently available to the production release notes shows that the beta fixes up to Nov 18, 2015 went to the production release for Dec 8, 2015 and the beta fixes up to Dec 22, 2015 (same date as latest beta) went to production on Dec 28, 2015 which the version for that date was 20.0.0.267. But there is no history of the previous beta release notes & what's currently available in the beta release notes doesn't even show the current beta version number since all it has is for 20.0.0.230 (which doesn't match the latest date) so its pretty sketchy on being able to determine why the beta version number scheme has dropped noticeably below the comparable production versions.

Another issue with them being further out of sync is that the production ActiveX version 20.0.0.270 was released on January 1st with no updates to the beta download pages, release notes, etc. I'm using too new of a version of Windows to verify what version for ActiveX is actually available for download although it appears to be as old as the other releases. Oh and this brings up another issue. The main beta page has the date of Dec 22, 2015 but the beta download page has the date of Dec 16, 2015 so they are not reliable either. So it appears that even if you ignore the number mismatches that the latest beta file isn't as new as the latest production version which is even more absurd.

All of these inconsistencies are seriously making me want to ditch the beta programs even though I've found & reported a couple crashes in the last year if they can't even keep track of which is what. Quite unprofessional for very popular software & a large company. Hopefully this will trigger some kind of audit to triple-check that all files, documentation, points of distribution & everything for both release channels are completely in sync. Please either explain or if not then at least just fix it all so things aren't such a mess.

This topic has been closed for replies.
Correct answer jeromiec83223024

Our priority, especially with out of cycle releases (emergency patch releases for security and functional escalations), is to get the ~2.5Bn people using the release channel into a good state.  Once that's taken care of, we typically try to follow up with a beta release that exceeds the release version within a few days.

December/January has been punctuated with an emergency security hotfix (while the entire company was on vacation) and a couple subsequent patches for functional fallout.  The beta channel has not been a priority target during this time.  The goal in general is to move the beta channel to a higher version than the release version within a couple days, but that's not always possible, particularly when we're operating with a skeleton crew.

We *will* be moving the beta channel forward to the next major version of Flash Player shortly. 

Your point is well-taken on the inconsistencies with the documentation.  I'd love for all of this stuff to be an artifact of the build system, but it's a manual, error-prone process at the moment.  It wasn't that long ago that Flash was on an 18-month release cycle, and beta releases came at 30-90 day intervals.  The team was roughly 3x larger as well. 

We've moved to a modern release cadence and have made huge security investments along the way, but the manual documentation processes persists and are fairly time-consuming.  There's clearly room for improvement, but the reality is that we have to make hard prioritization decisions, and things like beta documentation are secondary to keeping end-users safe and making sure that when security patches in the bowels of Flash have unfortunate, unforseen side effects, that those get resolved as quickly as possible.


We really do appreciate the testing effort that the beta community contributes, along with the huge amount of aggregate stability data that it generates.  The documentation and logistics for all releases (beta and otherwise) fall on the shoulders of a small handful of dedicated, hard-working people.  We're keen to help them out through better efficiency and automation, and we'll try to keep a closer eye on it in the interim.

Thanks!

1 reply

Colin Holgate
Inspiring
January 6, 2016

This slightly confusing situation does happen with both Flash Player and AIR. When the build changes from beta to release, only the release site is updated, the beta site keeps the latest beta. There was a release version a few days ago, and so until there is a new beta you get the situation where the release version is later than the most recent beta.

jeromiec83223024
Community Manager
jeromiec83223024Community ManagerCorrect answer
Community Manager
January 25, 2016

Our priority, especially with out of cycle releases (emergency patch releases for security and functional escalations), is to get the ~2.5Bn people using the release channel into a good state.  Once that's taken care of, we typically try to follow up with a beta release that exceeds the release version within a few days.

December/January has been punctuated with an emergency security hotfix (while the entire company was on vacation) and a couple subsequent patches for functional fallout.  The beta channel has not been a priority target during this time.  The goal in general is to move the beta channel to a higher version than the release version within a couple days, but that's not always possible, particularly when we're operating with a skeleton crew.

We *will* be moving the beta channel forward to the next major version of Flash Player shortly. 

Your point is well-taken on the inconsistencies with the documentation.  I'd love for all of this stuff to be an artifact of the build system, but it's a manual, error-prone process at the moment.  It wasn't that long ago that Flash was on an 18-month release cycle, and beta releases came at 30-90 day intervals.  The team was roughly 3x larger as well. 

We've moved to a modern release cadence and have made huge security investments along the way, but the manual documentation processes persists and are fairly time-consuming.  There's clearly room for improvement, but the reality is that we have to make hard prioritization decisions, and things like beta documentation are secondary to keeping end-users safe and making sure that when security patches in the bowels of Flash have unfortunate, unforseen side effects, that those get resolved as quickly as possible.


We really do appreciate the testing effort that the beta community contributes, along with the huge amount of aggregate stability data that it generates.  The documentation and logistics for all releases (beta and otherwise) fall on the shoulders of a small handful of dedicated, hard-working people.  We're keen to help them out through better efficiency and automation, and we'll try to keep a closer eye on it in the interim.

Thanks!

Mr_J_Rey
Mr_J_ReyAuthor
New Participant
January 27, 2016

Okay. I figured it was something along that line going on & glad to hear there's a reasonable plan of action. Thanks for the explanation!

My main issue was that the beta version kept crashing when going to full screen & I couldn't figure out heads or tails on if it was a known issue or fixed or what since reasonable research would be assumed before filing a bug report but I totally lost confidence on being able to do that. I've switched back to production version due to the delayed response here but will reconsider switching back to beta now that there is a response here & updates elsewhere. I may just only use the built-in Firefox crash reporting though at this point but we'll see.... Thanks again.