Sunday, September 18, 2005

Beta releases

Here and there I am browsing forums and blogs to see what people a doing with Flash 8. During those visits I sometimes come across posts of frustration. A typical comment would be something like this: "I wasn't worried since it was still a beta, but it seems Macromedia did not fix this bug for the final release!". Somehow that leaves me with frustration too since we genuinely try to address as many bugs as possible during the betas. But there seem to be a few misconceptions of what public betas of the Flash Player are really about. I am not sure if that is a communication problem on our side, but let me put out a few blunt points:

  • To debunk a common myth: Public beta versions do not contain any type of special debug code or information. What you get as a beta is essentially the same thing you'll get upon release.

  • Public betas are considered functionally complete. Otherwise we'd call it a 'preview' or 'alpha' release. If you see something missing or non functional, it'll be missing and not working in the final release unless you tell us.

  • Public betas are fully performance optimized. If something runs slower, it'll be running slower in the final release unless you tell us.

  • Public betas will break existing content. It always does despite our best efforts of manually testing huge amounts of existing sites and having large automated test systems. Unless reported to us chances are high it will remain broken.

  • Public betas are released months before the final release. This is because a bug life cycle can average 2 weeks. If a bug is reported to us 2 weeks or less before a release, chances are high it will not be fixed unless it is catastrophic (meaning a security issue or crasher).

  • While posting about bugs on blogs and forums is informative to the community, we sometimes miss these as we are extremely busy during beta time as you can imagine. So please, please take a few seconds and use the bug reports forms or if you really can't stand the impersonal feel of this, email someone at Macromedia about your problem. Before the final release. :-)

11 Comments:

Anonymous John Dowdell said...

Please don't be too frustrated though, Tinic... there's also a social component to "first bug" posts. (When a conversation is mostly about a new release and positive, there's strong incentive for the "yes, but" position to emerge... too many "i love this!" posts leads to a need for "but they didn't even do that!" responses.)

There's also the varying definition of "bug" to deal with -- for some people the fact that the Player does not have built-in RegExp "is a bug", or waiting while a 2M XML file is processed "is a bug". The label is mainly a judgment about what we're seeing, rather than direct observation, and so use of the label varies from person to person.

I'm not sure the company has systematically differentiated "public beta", "preview" and "alpha" in that fashion... may hold true for the last few Player releases, but I'm not sure about other product groups. (I've informally called the early Player releases "compatibility testing releases" or stuff like that, because a lot of the conversation has been about groovy new features instead of that vital work of testing support for existing projects.)

With all "bug" discussions it's important to show how other people can see what you're seeing, how it can be made to happen fresh, rather than just arguing about the label from different experience. (That commonly-discussed "pixel-doubling bug" has had at least half-a-dozen different functional definitions from varying speakers!)

Monday, September 19, 2005 7:48:00 AM  
Anonymous Mike M said...

Just out of interest, is their a list on known bugs that haven't been fixed?

Monday, September 19, 2005 9:15:00 AM  
Anonymous eokyere said...

Tinic,

my 2 cents? stick to the technical posts :P

Monday, September 19, 2005 11:36:00 AM  
Anonymous Anonymous said...

Macromedia might consider a bug reporting system that shows what has been reported.

How are we users to know that the bug we just found hasn't already been reported to you 100 times?

And.. how are we supposed to know when the cutoff is for reporting these bugs? We aren't told when betas are going to begin, or when they are going to end.

Monday, September 19, 2005 1:33:00 PM  
Anonymous Emmy said...

We did include a list of "known issues" in the Flash Player 8 release notes (http://www.macromedia.com/support/documentation/en/flashplayer/8/releasenotes.html#issues). This is not a comprehensive list; we included issues that were most likely to be encountered by users or developers in using the latest Player.

For issues that do not happen for everyone or require more than one sentence to describe the issue or its workaround, we created tech notes. I think the best way to look for the most recent notes might be to search the Knowledge Base for "Flash Player 8."

best,
Emmy

Monday, September 19, 2005 3:59:00 PM  
Anonymous Emmy said...

This post has been removed by a blog administrator.

Monday, September 19, 2005 4:27:00 PM  
Anonymous Anonymous said...

Flash 8 is a great product, one area that lets it down is the debug tool.

For example create a instance of a filter and all its properties show up in the debug as undefined.

yet a trace on a known property shows its true value;

Whilst this is a good release for designers, coders may feel neglected.

Tinic try using the IDE to code a large flash applications with dozens of class files for a few days and you will see what I mean, and you will understand why so many developers use other tools to code AS2 but debugging is a real pain and the biggest bottleneck to rapid development in Flash

Please turn your excellent attention to the IDE and the Debug

Thursday, September 22, 2005 9:38:00 AM  
Anonymous Mauviere said...

I have been using Flash since release 3, and Flash 8 is really a great tool, especially for webmapping applications.

I was however surprised to discover last week how easy it was to crash the F8 IDE or the F8 player in a browser, with the ContextMenu object :
1) place a button (btn) on the scene
2) this code on the main timeline :
btn.onRollOver = function() {
var cm = new ContextMenu();
cm.customItems.push(new ContextMenuItem("test onRollOver...", testHandler));
_root.menu = cm;
};
btn.onRollOut = function() {
_root.menu = undefined;
};
function testHandler(obj, item) {}
3) crash when clicking "test onRollOver..." in the ContextMenu
Note : crash does not occur with F7 player

Monday, September 26, 2005 12:21:00 AM  
Blogger kirk said...

We just noiticed this also but I have not been able to find a solution yet. What we did notice was that in a context menu that has 2 items ( in player 7 ), there is only one now and when you select it, the browser crashes. Could it be some out of range error in the menuItems?

Ideas of a fix? 8.5 release?

Ouch, because it was one of the nicer UI features we added to our application and now, bingo...

C

Thursday, December 08, 2005 6:39:00 AM  
Anonymous Anonymous said...

I've got the same problem with my internet favorites web page (www.e-poke.com). As soon as I try to delete a directory with a context menu, it crashes with flash 8.... What is strange is that if I delete a "quick bookmark" with a context menu it does not... It seems to crash only with directory and the LAST bookmark of each directory!
As soon as you've got a workaround, let me know. Again it was not a problem in flash 7.... But how to go back to flash player 7. Indeed, when you browse the internet, you always find sites which ask you to download the last flash player 8....

Friday, December 23, 2005 2:59:00 AM  
Anonymous <a href="http://drugscenterhere.com">ShopMan</a> said...

I like articles like this. Thanks!

Sunday, August 26, 2007 12:38:00 AM  

Post a Comment

<< Home