"New" way to refer to Fx 4 Beta
Laura Mesa
As we continue in the Firefox 4 Beta development cycle, we wanted to
send out a note to get everyone on the same page when publicly referring
to the latest beta release.
In the past, we have referred to our beta updates numerically; for
example, beta 1, beta 2, or beta 3. We agree that this is a very helpful
way to keep track of specific releases, especially within engineering,
and we should continue to do so.
Publicly, however, we think its best to start moving away from
associating a number to a particular release. As of now, we have 7
scheduled Betas, and there is a possibility that we may need to have
more. Potentially having to call out Firefox 4 Beta 9 in tweets, blogs,
videos or social media could start to make it look like we've had an
inefficient development cycle, and that--as well all know--couldn't be
farther from the truth.
From now on, it would be great to refer to Firefox 4 Beta without the
release number, referring instead to release as the "latest beta update"
or the "newest beta release". Doing so would go a long way to make sure
we prevent negative news stories about the length of the development
cycle as we prepare for RCs and finally, GA.
To be clear, we aren't going to be super strict on this or monitor how
people are referring to the beta--far from it! We just wanted to send a
general note out so that everyone is aware of what we're trying to do
and why, hopefully ensuring that we have the most effective messaging in
the market that we can.
Thanks for all your help--we're looking forward to an awesome Firefox 4!
Cheers,
Laura
PS Also, don't forget to use #Fx4 or #fx4beta when tweeting about any of
the coming beta releases!
--
Laura Mesa
Mozilla Product Marketing Manager
lm...@mozilla.com
650-903-0800 ext 329
johnjbarton
> Hi all,
>
> As we continue in the Firefox 4 Beta development cycle, we wanted to
> send out a note to get everyone on the same page when publicly referring
> to the latest beta release.
>
> In the past, we have referred to our beta updates numerically; for
> example, beta 1, beta 2, or beta 3. We agree that this is a very helpful
> way to keep track of specific releases, especially within engineering,
> and we should continue to do so.
>
> Publicly, however, we think its best to start moving away from
> associating a number to a particular release. As of now, we have 7
> scheduled Betas, and there is a possibility that we may need to have
> more. Potentially having to call out Firefox 4 Beta 9 in tweets, blogs,
> videos or social media could start to make it look like we've had an
> inefficient development cycle, and that--as well all know--couldn't be
> farther from the truth.
The truth here is that the Beta 1-5 were what the community calls
'alpha' releases. See for example
http://en.wikipedia.org/wiki/Software_release_life_cycle
---
"Beta" is the software development phase following alpha, named after
the Greek letter beta. It generally begins when the software is feature
complete.
---
So the reason you have to go to beta 9 is that you started counting
betas too soon.
I understand that the Firefox team wants feedback from a larger class of
users early in the development. You have legitimate reasons for using a
different software release life cycle. One reasonable solution is to
introduce a new cycle to the community:
a : early development
b : design feedback
c : feature freeze
So change b5 to c1 then do that tweet thing about your innovation here.
>
> From now on, it would be great to refer to Firefox 4 Beta without the
> release number, referring instead to release as the "latest beta update"
> or the "newest beta release". Doing so would go a long way to make sure
> we prevent negative news stories about the length of the development
> cycle as we prepare for RCs and finally, GA.
Deliberately obscuring information vital to how users communicate about
problems in Firefox cannot possibly make your product better.
We anxiously await FF 4.0b4,
jjb
Shawn Wilsher
> The truth here is that the Beta 1-5 were what the community calls
> 'alpha' releases. See for example
> http://en.wikipedia.org/wiki/Software_release_life_cycle
> ---
> "Beta" is the software development phase following alpha, named after
> the Greek letter beta. It generally begins when the software is feature
> complete.
> ---
> So the reason you have to go to beta 9 is that you started counting
> betas too soon.
can only begin then. We seem to fit all the criteria listed there for
"beta". Additionally, I don't think any browser vendor is feature
complete when it ships a beta.
> Deliberately obscuring information vital to how users communicate about
> problems in Firefox cannot possibly make your product better.
I don't see how this is obscuring. Not sure most people care about the
number other than knowing that they are on the latest version. Care to
elaborate?
Cheers,
Shawn
Mike Beltzner
Laura's message is more talking about how to communicate about these changes to the "wider public", meaning press, tweets, etc. It's mostly about image and messaging, but those are important parts of a release.
If you're unlikely to be tweeting, or to have your blog posts read by the mainstream press or users, you don't need to spend a lot of time thinking about this. Within our development and testing community we'll still be referring to milestones by their beta version numbers.
At the same time, when promoting the beta to your friends, we'd like (as Laura says) for people to think about the beta as an ongoing program which will see their browser updated many times as we iterate towards success!
Thanks for your help.
cheers,
mike
John J Barton
> On 8/18/2010 12:10 AM, johnjbarton wrote:
>> Deliberately obscuring information vital to how users communicate about
>> problems in Firefox cannot possibly make your product better.
> I don't see how this is obscuring. Not sure most people care about the
> number other than knowing that they are on the latest version. Care to
> elaborate?
But design or development releases are not about "most people" or about
the "latest version". These releases exist specifically for evaluating
and testing the product. These releases change dramatically, they are
really different. All communications about issues in the evaluation and
testing need to include specific reference to the version. Otherwise we
cannot tell whether new issues are regressions or just users on an older
version. The only practical response to a bug report or question about
the "latest" version is to ask for the version number so you can give an
accurate answer.
Please consider my suggestion.
jjb
Bill Braun
Anyone who knows what a beta release is will conclude quite the
opposite - that progress is moving forward at a nice clip. Anyone who
doesn't know what a beta release is won't care and will likely wait
until the update notice appears when they load FF or TB.
There is a deeper issue here that, in my opinion, ought to be an open
conversation. The conclusion that people will interpret successive beta
releases as negative was supported by the same amount of data and
evidence as my conclusion that they will be received positively or
neutrally - no evidence or data at all. What was the basis for drawing
such a conclusion? It sounds like a SWAG, but, there might be evidence
or data behind the statement. None was offered.
I am developing a perception that a good deal of decision making is
following this path, i.e., "well, it sounds like it makes sense, so
let's run with it". It appears to me that TB 3.x has been a long string
of "makes sense, let's run with it" decisions without a lot of critical
thinking and analysis, and very little anticipation of how it will work
in the field.
My confidence in TB has been considerably shaken with the
3.x release (I acknowledge that perception is arguable). This "like it,
run with it" level of thinking (my interpretation, I admit, and I take
ownership for my conclusions) does not bode well for TB or FF.
I mean none of this personally nor do I wish or intend to diminish
persons or efforts. I'm not naive about the effort it takes to create
and maintain direction and focus with a group of people who are
volunteers and who have desires and hopes of their own. I know what it
is like to have a lot of energy around an idea that is out of sync with
the direction in which the beast is expected to flow.
An effective exercise for gaining insight is to ask a number of your
best developers to sequester themselves and spec out a product that
would kill TB in the minds of its current users and give them cause to
adopt the new product en-mass. This is the magnitude of shift that ought
to take place. It would energize people around a very clearly
articulated end result, something that I think has died, or is quite ill.
Bill B
Mike Beltzner
> The conclusion that people will interpret successive beta
> releases as negative was supported by the same amount of data and
> evidence as my conclusion that they will be received positively or
> neutrally - no evidence or data at all.
Actually, it's based on previous experience, where the technical press has often referred to the number of betas as a proxy for the ability for an organization to ship software on schedule. We wish it were not so, truly.
> am developing a perception that a good deal of decision making is
> following this path, i.e., "well, it sounds like it makes sense, so
> let's run with it"
I am, of course, sorry that you feel this way. Happily, all of our decision making and discussion takes place in open fora like this, so you can base such conclusions on evidence, and see the evidence of us bringing data to bear when making decisions. When it is available and interpretable, we definitely do so. When it isn't, we try to get it. When we can't get hard data, we use secondary sources, or yes, sometimes (though rarely) make a call. Decision making is hard, let's go shopping.
The rest of your message was about Thunderbird, and not really on topic.
cheers,
mike
Ron Hunter
Chrome for their beta development. Clear, concise, and they don't care
if people know they have 39 versions of this beta iteration.
Ron Hunter
different, versions, though. The latest beta is non-specific, and
potentially very confusing.
Ron Hunter
version/build number from the software, and attaches it to the response.
If not, it certainly SHOULD. At least then the developers will know
explicitly what software has the specified problem. As for user support
issues, these messages often don't include the necessary information.
Ron Hunter
I agree that perception is very important, but then so is accurate
communication between developers and those of us who expose ourselves to
beta versions of various software. I have been doing that since about
1984, so I have so many scars that I rarely feel much pain when
something just doesn't work, or I find my favorite add-on just won't
work with this or that version. I really don't care WHAT a version is
called in the media, or someone's tweet, or blog, or on Facebook, as
long as it doesn't interrupt the flow of accurate information between
beta testers and developers.
One caution, it is often easy to over think things like this.
Mike Beltzner
> I agree that perception is very important, but then so is accurate communication between developers and those of us who expose ourselves to beta versions of various software. I have been doing that since about
As I, and Laura, have stated pretty clearly, this isn't going to change the way that the development community talks amongst itself about the beta versions. We're talking specifically about:
- tweets/facebook wall comments/buzzes advertising features or technology,
- posts written in mainstream/public places (Mozilla Hacks, Mozilla Newsletter, etc)
That's it. Everyone else can continue to do as they wish. And indeed, anyone can always do what they wish. This was simply a request from the people responsible for messaging, sharing the fact that the messaging they will be doing will use terms like "next beta refresh", etc, and the rationale behind that.
Everyone can stop talking about this now, I'm pretty sure. I'm honestly thrilled that it's the most alarming or interesting part of your day.
cheers,
mike
Asa Dotzler
Ron, you are correct on both counts. We get it automatically when we can
and when we can't and have to ask for it, we almost always want more
information than just the beta number.
Both the user feedback system and the support system have other means of
gathering this information that are far more reliable than our public
messaging around beta names. Our feedback system reports the build info
and support requests include browser user agent info automatically. When
that's not sufficient, support can ask for about:support details. Oh,
and bugzilla gets UA info too.
Our public messaging does nearly nothing to help feedback and support.
and unless you actually work regularly with our support effort or our
feedback system, please don't assert that it does.
- A
Asa Dotzler
> Will only contribute to confusion. Look at the method used by Google
> Chrome for their beta development. Clear, concise, and they don't care
> if people know they have 39 versions of this beta iteration.
>
I've been testing the developer channel and the beta channel as long as
Chrome's had them and for the last while I've also been testing the
Canary channel. No one uses numbers other than the primary upcoming
version and the channel (dev, beta, canary) when talking about all of
these. I also follow a lot of bug report that comes in to Chromium and
they are all filed with a build ID or are requested to add specific
build IDs in early comments (like in the case they used a different
browser to file the report.)
I never know which Canary build or which beta build I'm on with Chrome -
ever, until I open up the About Google Chrome dialog and see that I'm on
6.0.496.0 canary build, for example. Almost no one uses the full "Chrome
6.0.496 canary build" or "Chrome 6.0.495 dev" when talking about these
versions in blogs or tech press.
It's just "Chrome 5 Beta" or "Today's Chrome Dev build" or "the latest
Chrome Canary build"
- A
Ron Hunter
> beta 4 when we're talking in our various forums. And for the rest of the
> world, like the blogs and tech press, I doubt we'll have any serious
> confusion here given the context of most of that content.
>
> - A
>
I agree. Since I don't do blogs, and take tech press with a whole
barrel of salt, I don't have any comments to them. I guess I am safe
from causing confusion, of being confused about the exact version/build.
I do feel that the term 'latest beta' is rather subject to mislead,
given that publication delays are usually going to make their version
rather old, even in these days of electronic communications.
David E. Ross
If I encounter a regression bug, I would think the developers would like
to know that the regression occurred somewhere between Beta 5 and Beta 8
even if the current one is Beta 11.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross
James May
be less confusing/demeaning to the product.
(This is the same way that the Internet Explorer team refers to
pre-releases, for better or worse)
-- James
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
Aleksej
> To be clear, we aren't going to be super strict on this or monitor how
> people are referring to the beta--far from it! We just wanted to send a
> general note out so that everyone is aware of what we're trying to do
> and why, hopefully ensuring that we have the most effective messaging in
> the market that we can.
In Wikinews, names of all articles in a particular language are in the
same namespace.
Robert Kaiser
> Potentially having to call out Firefox 4 Beta 9 in tweets, blogs,
> videos or social media could start to make it look like we've had an
> inefficient development cycle, and that--as well all know--couldn't be
> farther from the truth.
Maybe I'm just different, so take this with a grain of salt, but when I
see different (pre-)releases called out with the same name and using
workaround descriptions like "the latest beta", _then_ I start to think
their release system is broken. When they call out "beta 15" I just tend
to think "looks like they test for a very long time until they find they
can release a final". ;-)
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
KWierso
To be fair, though, Chrome has that background update service, so
pretty much everyone is on the "latest" Chrome build.
Daniel
> Laura Mesa schrieb:
>> Potentially having to call out Firefox 4 Beta 9 in tweets, blogs,
>> videos or social media could start to make it look like we've had an
>> inefficient development cycle, and that--as well all know--couldn't be
>> farther from the truth.
>
> Maybe I'm just different, so take this with a grain of salt, but when I
> see different (pre-)releases called out with the same name and using
> workaround descriptions like "the latest beta", _then_ I start to think
> their release system is broken. When they call out "beta 15" I just tend
> to think "looks like they test for a very long time until they find they
> can release a final". ;-)
>
> Robert Kaiser
>
Hey, Robert, haven't we had two SeaMonkey 2.1a2's??
O.K., these were only alpha's and were with-in a couple of days (if not
sooner), but.......
Daniel
Robert Kaiser
> Hey, Robert, haven't we had two SeaMonkey 2.1a2's??
No. We had two candidate builds for it, but only one that was released
and announced on websites, etc.
Nobody would be happy if we didn't correct builds before we released
them when we found errors that are not release-worthy (not even for an
alpha or beta).
Laura Mesa
Just wanted to address some of the concerns that my earlier email
raised. We absolutely want to continue with rapid product development
cycles and launching the best product we can -- when we're ready. I did
not intend to imply that we should be hiding from the fact that we are
shipping milestones for feedback frequently. I can see how the wording
of my earlier email might have been misinterpreted and I apologize for
that.
So far, our Beta has been very well received and we want to continue to
focus the discussion on the features and the functionality in the
product. We want to make sure that our users are aware that Firefox 4
Beta is awesome, no matter the version, and that they should download it
and help us test. We were concerned that the numbering system might
have gotten in the way of that message, but at the end of the day, our
goal is to get people using the beta and excited about the final release.
Thanks,
L
Laura Mesa wrote:
> Hi all,
>
> As we continue in the Firefox 4 Beta development cycle, we wanted to
> send out a note to get everyone on the same page when publicly
> referring to the latest beta release.
>
> In the past, we have referred to our beta updates numerically; for
> example, beta 1, beta 2, or beta 3. We agree that this is a very
> helpful way to keep track of specific releases, especially within
> engineering, and we should continue to do so.
>
> Publicly, however, we think its best to start moving away from
> associating a number to a particular release. As of now, we have 7
> scheduled Betas, and there is a possibility that we may need to have
> more. Potentially having to call out Firefox 4 Beta 9 in tweets,
> blogs, videos or social media could start to make it look like we've
> had an inefficient development cycle, and that--as well all
> know--couldn't be farther from the truth.
>
> From now on, it would be great to refer to Firefox 4 Beta without the
> release number, referring instead to release as the "latest beta
> update" or the "newest beta release". Doing so would go a long way to
> make sure we prevent negative news stories about the length of the
> development cycle as we prepare for RCs and finally, GA.
>
> To be clear, we aren't going to be super strict on this or monitor how
> people are referring to the beta--far from it! We just wanted to send
> a general note out so that everyone is aware of what we're trying to
> do and why, hopefully ensuring that we have the most effective
> messaging in the market that we can.
>
> Thanks for all your help--we're looking forward to an awesome Firefox 4!
>
> Cheers,
>
> Laura
>
> PS Also, don't forget to use #Fx4 or #fx4beta when tweeting about any
> of the coming beta releases!
>
>
>
"snap at geckozone dot, wait for it, org"
> Perhaps a change of language to something like "Firefox 4 Preview x" would
> be less confusing/demeaning to the product.
>
> (This is the same way that the Internet Explorer team refers to
> pre-releases, for better or worse)
>
> -- James
This is exactly what I wanted to add.
Mozilla obviously needs to keep working -- and communicating -- with
version numbers. Everyone does not use the feedback add-on, or does not
update their Firefox beta.
People should be able to report accurate feedback: "I have this problem
with Firefox 4 [Beta/Preview/whatever you call it] number 12".
What follows is more targeted towards Laura Mesa:
I don't think releasing many "beta" sounds the product quality is bad.
__It depends on your way on communicating on it__. Call them "preview
release" and you look like a company which keeps in touch with its
users. Isn't it marketing magic ;-) ?
Some products are better when they are mature: cheese, whiskey... --
well, the latter is probably not a good advertising idea for children.
IMHO you should be proud of your development cycle, and show it. Yes, I
had understand you wanted to try to hide it like a shameful thing. Glad
to read I was wrong.
> We want to make sure that our users are aware that Firefox 4 Beta is awesome, no matter the version, and that they should download it and help us test.
With all the respect I have for the quality assurance and development
teams, a beta is not a complete product (that's why it's called beta).
It may explode, open security breaches, and I would not recommend it to
my relatives so they would not be disappointed if something goes wrong.
But I guess you were talking about power users.
--
Snap
Daniel
> Daniel schrieb:
>> Hey, Robert, haven't we had two SeaMonkey 2.1a2's??
>
> No. We had two candidate builds for it, but only one that was released
> and announced on websites, etc.
> Nobody would be happy if we didn't correct builds before we released
> them when we found errors that are not release-worthy (not even for an
> alpha or beta).
>
> Robert Kaiser
>
O.K, so there was an unofficial release on SM 2.1a2 (which I
downloaded), problems were found and fixed and an official release
version of SM 2.1a2 was released (which I downloaded).
If it's just an alpha, and was different, why not just name it a3??
Not that I'm really complaining, just wondering!
Daniel
Robert Kaiser
> If it's just an alpha, and was different, why not just name it a3??
Because the first build was never "released". It was an internal testing
version - for whatever "internal" means in an open community and project
solely driven by volunteer contributors.
It at least wasn't written about anywhere but our development-only
channels or the Mozilla QA group.
Mike Kristoffersen
> Mozilla obviously needs to keep working -- and communicating -- with
> version numbers. Everyone does not use the feedback add-on, or does not
> update their Firefox beta.
> People should be able to report accurate feedback: "I have this problem
> with Firefox 4 [Beta/Preview/whatever you call it] number 12".
Why not use the build date as the reference, like Firefox 4 Preview
Aug23-2010, a bit longer but actually giving more information than just
an integer.
Btw. I think there are a lot of good points in your post
^__^
MikeK
Daniel Holbert
> On 2010-08-21 04:05, "snap at geckozone dot, wait for it, org" wrote:
>> People should be able to report accurate feedback: "I have this problem
>> with Firefox 4 [Beta/Preview/whatever you call it] number 12".
>
> Why not use the build date as the reference
Both of those pieces of information (beta # and build date) remain easily
available via "About Firefox" in the Help menu.
Laura's message was strictly about PR, not about removing version
identifiers from within the product itself.
Mike Kristoffersen
I'm aware of the above - what I was trying to say is that when I talk to
my friends about an obscure bug, or cool new feature, then I would
probably have no idea if it is in the latest beta.
If I read an article or blog post - I would have no idea if "Latest
beta" is the current latest version of the software, or if there has
been several releases since it was written - what the writer (at the
time of writing) might think is the latest beta, would be unlikely to be
the latest beta at the time I read the article, especially if it is in a
printed magazine.
As a developer I would probably be sad to see a bug mentioned as being
in the "Latest beta" if it was fixed 2 months ago.
Using version numbers is one way of solving this, I was suggesting using
the date instead, as most people have some relationship to the concept
of time and one can assume that the progress of the software is more or
less a function of time, whereas the difference between two beta
versions could be a day or a month, you would have no way of knowing
without actively searching that information.
Just my thoughts on the subject...
^__^
MikeK
Tony Mechelynck
The first one was named a2 RC1 (and tested by the testers community,
then found not to be release-worthy even for an alpha, and not
released). The second one was named a2 RC2, then found OK and released
as a2 (a2 Release if you want). Like all RC builds, their user-agent
string had in both cases only the "future release" number
(SeaMonkey/2.1a2) because any release-candidate which is found good
enough for a release is released "as is", without changing anything (not
even the UA text) and without recompiling. This is also why, by the time
a release (of any Mozilla-family product) is announced, the
Gecko/yyyymmdd datestamp in its UA string is always already "measurably
old": that same build started its life as a release-candidate.
In fact, these two release-candidates differed in the datestamp in the
UA — which no-one, not even developers, mentions when talking casually,
but it may be regarded as an additional refinement to the release number
(especially when talking about nightlies or hourlies), it is there for
when you need to refer to it, and as you know (or ought to) it is pasted
automatically in the Bugzilla reports filed from the guided form, or
pasted manually by power reporters when they think it might be useful,
for instance in order to determine a regression window.
>
> Not that I'm really complaining, just wondering!
>
> Daniel
Best regards,
Tony.
--
There can be no twisted thought without a twisted molecule.
-- R. W. Gerard
Chris Ilias
> From now on, it would be great to refer to Firefox 4 Beta without the
> release number, referring instead to release as the "latest beta update"
> or the "newest beta release". Doing so would go a long way to make sure
> we prevent negative news stories about the length of the development
> cycle as we prepare for RCs and finally, GA.
The Windows desktop shortcut says "...Beta 1", and when I use the
Firefox Update system to update to Beta 2 (then 3, then 4), the desktop
shortcut still says "Beta 1".
I was going to file a bug so that the desktop shortcut gets updated with
each beta release, but it sounds like this discussion could be applied
to the desktop shortcut as well. What do you think?
Robert Strong
only applied to alpha / beta builds which would be adding complexity
that would not get tested most of the time and might cause problems with
release builds. There have been bugs filed for this a couple of times
before which have been wontfix because of these reasons.
Robert
Robert Strong
> On 8/24/2010 5:33 PM, Chris Ilias wrote:
> that only applied to alpha / beta builds which would be adding
> complexity that would not get tested most of the time and might cause
> problems with release builds. There have been bugs filed for this a
> couple of times before which have been wontfix because of these reasons.
other term that wouldn't need to be updated for each release.
Robert
Mike Beltzner
> btw: I wouldn't be at all adverse to it just saying preview or some
> other term that wouldn't need to be updated for each release.
That should be the solution, yes. Just "Firefox 4 Beta."
cheers,
mike
Snap
On 19/08/2010 02:11, Mike Beltzner wrote :
> As I, and Laura, have stated pretty clearly, this isn't going to change the way that the development community talks amongst itself about the beta versions. We're talking specifically about:
I still don't get why there would be two ways of communicating. An
"expert way", which is allowed to give beta numbers, and a "public way",
which says "It-Who-Must-Not-Be-Numbered".
> - tweets/facebook wall comments/buzzes advertising features or technology,
> - posts written in mainstream/public places (Mozilla Hacks, Mozilla Newsletter, etc)
Mozilla Hacks too ? I don't think the targeted public needs it.
> Actually, it's based on previous experience, where the technical press has often referred to the number of betas as a proxy for the ability for an organization to ship software on schedule. We wish it were not so, truly.
If some people running a website, self-proclaimed "journalists", use the
greta number of your beta versions to say bad things about you, everyone
here will agree they are not serious. And should not be listened.
It's a bit scary to learn you are changing our communication strategy
because of people like this. Instead of explaining why it is better to
test longer, you prefer to hide them the number of your beta ? Seriously ?
Why am I the only one to ask on this ? Did I misread/understand something ?
If you hide beta numbers to the public, pseudo-journalists will still be
able to find them. And publish about it.
The way you do means their reasoning is true.
--
Snap