Why does Fx 5.0b2 report its version as 5.0
al...@yahoo.com
clue as to what build this is.
Gavin Sharp
to call RCs, so the branding/versioning matches release builds.
Gavin
On Fri, May 20, 2011 at 11:28 PM, <al...@yahoo.com> wrote:
> Neither the about dialog, nor the about: and about:support pages, give any
> clue as to what build this is.
>
>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
al...@yahoo.com
news:mailman.383.1305949653...@lists.mozilla.org...
> That's intentional. The new "beta channel" is closer to what we used
> to call RCs, so the branding/versioning matches release builds.
>
Are you saying that b2 could become the release? Because if not, this
policy makes no sense, it should be possible to know what version one is
running.
Boris Zbarsky
> it should be possible to know what version one is running.
about:buildconfig has that information, no? Specifically, the changeset
if the build was created from.
Or did you mean some other arbitrary number that may happen to be
attached to the actual code you're running? Why is it necessary for
anyone to know that, if I might ask?
During the Firefox 4 cycle there were some incidents of sites "fixing"
problems by sniffing for the string "4.0b" in UA strings. They broke
again once Firefox 4 final shipped, and our users were the ones who had
to deal with the resulting pain. We don't need that happening again.
-Boris
al...@yahoo.com
news:LaedncuEj_BQ30rQ...@mozilla.org...
> On 5/21/11 12:29 AM, al...@yahoo.com wrote:
>> it should be possible to know what version one is running.
>
> about:buildconfig has that information, no? Specifically, the changeset
> if the build was created from.
One should have to open a remote web page to know what version is installed
on the local machine? Why?
>
> Or did you mean some other arbitrary number that may happen to be attached
> to the actual code you're running? Why is it necessary for anyone to know
> that, if I might ask?
>
The version is not arbitrary, it's the 5.0b2 realese build, and there is no
reason it should be hidden. There are plenty of situations when testing
something in Fx or an extension, and other scenarios, when one needs to know
what version is running.
> During the Firefox 4 cycle there were some incidents of sites "fixing"
> problems by sniffing for the string "4.0b" in UA strings. They broke
> again once Firefox 4 final shipped, and our users were the ones who had to
> deal with the resulting pain. We don't need that happening again.
>
That's a strawman, I did not ask about the UA, it can stay constant, but
there is no justification for hiding the real version from the user.
Boris Zbarsky
> "Boris Zbarsky"<bzba...@mit.edu> wrote in message
> news:LaedncuEj_BQ30rQ...@mozilla.org...
>> On 5/21/11 12:29 AM, al...@yahoo.com wrote:
>>> it should be possible to know what version one is running.
>>
>> about:buildconfig has that information, no? Specifically, the changeset
>> if the build was created from.
>
> One should have to open a remote web page to know what version is installed
> on the local machine? Why?
about:buildconfig is not remote any more than about: is. In fact, it's
implemented in _exactly_ the same way.
Or did you mean that changeset URI? The fact that it's a URI is just a
convenience. The version is the actual URI string. For example, right
now I am running version
"http://hg.mozilla.org/mozilla-central/rev/9e31df64bfd7". That's just
as good a version indicator as any other versioning string (e.g.
"Mozilla nightly 2011-05-09" or anything like that), no?
>> Or did you mean some other arbitrary number that may happen to be attached
>> to the actual code you're running? Why is it necessary for anyone to know
>> that, if I might ask?
>
> The version is not arbitrary
Sure it is.
> it's the 5.0b2 realese build
That "5.0b2" string is completely arbitrary.
> and there is no reason it should be hidden.
There are plenty of reasons to hide it from _websites_. There are no
good reasons to hide it from the user, but right now the code can't show
different things to the user and to websites, unfortunately.
> There are plenty of situations when testing
> something in Fx or an extension, and other scenarios, when one needs to know
> what version is running.
Can you describe one of those situations, exactly? I'd really like to
understand it.
> That's a strawman, I did not ask about the UA, it can stay constant, but
> there is no justification for hiding the real version from the user.
There is no infrastructure in place for showing different things to the
user. about: just shows the UA string, whatever it is. Always has; if
you spoof your UA it shows the spoofed UA.
-Boris
al...@yahoo.com
> On 5/21/11 1:17 AM, al...@yahoo.com wrote:
>> "Boris Zbarsky"<bzba...@mit.edu> wrote in message
>> news:LaedncuEj_BQ30rQ...@mozilla.org...
>>> On 5/21/11 12:29 AM, al...@yahoo.com wrote:
>>>> it should be possible to know what version one is running.
>>>
>>> about:buildconfig has that information, no? Specifically, the changeset
>>> if the build was created from.
>>
>> One should have to open a remote web page to know what version is
>> installed
>> on the local machine? Why?
>
> about:buildconfig is not remote any more than about: is. In fact, it's
> implemented in _exactly_ the same way.
>
> Or did you mean that changeset URI? The fact that it's a URI is just a
> convenience. The version is the actual URI string. For example, right
> now I am running version
> "http://hg.mozilla.org/mozilla-central/rev/9e31df64bfd7". That's just as
> good a version indicator as any other versioning string (e.g. "Mozilla
> nightly 2011-05-09" or anything like that), no?
That uri is random noise, a meaningful and useful version to the user is
something like the tag FIREFOX_5_0b2_RELEASE, to get to which you have to
open the uri. Incidentally, I notice the devs don't deny themselves helpful
version tags in source control.
>
>>> Or did you mean some other arbitrary number that may happen to be
>>> attached
>>> to the actual code you're running? Why is it necessary for anyone to
>>> know
>>> that, if I might ask?
>>
>> The version is not arbitrary
>
> Sure it is.
>
>> it's the 5.0b2 realese build
>
> That "5.0b2" string is completely arbitrary.
>
>> and there is no reason it should be hidden.
>
> There are plenty of reasons to hide it from _websites_. There are no good
> reasons to hide it from the user, but right now the code can't show
> different things to the user and to websites, unfortunately.
>
>> There are plenty of situations when testing
>> something in Fx or an extension, and other scenarios, when one needs to
>> know
>> what version is running.
>
> Can you describe one of those situations, exactly? I'd really like to
> understand it.
Have you really never had a reason to identify and possibly communicate a
version of some software you're running?
1) You discover a possible problem in Fx or an extension. You want to
discuss the problematic behavior, it should be trivial to identify the build
and communicate it it to others.
2) Your are running two or more builds simultaneously side by side to trace
how some behavior changed. Again it should be trivial to get the exact
version from a running instance.
3) You fire up the currently installed beta which you haven't run in a
while, and just want to know what the hell you're running.
Are you planning to carry this over to release builds? Are all security/bug
fix releases going to report 5.0?
>
>> That's a strawman, I did not ask about the UA, it can stay constant, but
>> there is no justification for hiding the real version from the user.
>
> There is no infrastructure in place for showing different things to the
> user.
Well, there should be, if there are legitimate reasons for hiding the
version from websites, there aren't for hiding it from the user.
Boris Zbarsky
> That uri is random noise, a meaningful and useful version to the user is
> something like the tag FIREFOX_5_0b2_RELEASE
How about "current beta of Firefox 5"? The dialog does tell you that, fwiw.
> Have you really never had a reason to identify and possibly communicate a
> version of some software you're running?
I have, but see below.
> 1) You discover a possible problem in Fx or an extension. You want to
> discuss the problematic behavior, it should be trivial to identify the build
> and communicate it it to others.
To which others? If you're communicating it to _me_ for example, in my
capacity as a someone working on Gecko, I don't care that much what
version string is showing for you; I do care what code is running (and
the changeset is the way to identify that).
I grant that if you want to discuss this with people who are not dealing
with the source you may want some other shorthand for particular builds.
But what happens if we start doing daily updates on the beta channel?
Should we end up with a b42 by the time it becomes final? It really
doesn't make that much sense to rev a "version number" for every single
change on the beta channel. I mean, I suppose we could do that, so
you'd have a version number like 5.0b39 or 5.0.1.39 in Chrome-land, say.
Is that really more useful for discussion than the changeset id? I
guess you can immeditely tell which one is newer with this sort of
notation....
> 2) Your are running two or more builds simultaneously side by side to trace
> how some behavior changed. Again it should be trivial to get the exact
> version from a running instance.
In this case, once again, I think the changeset id is more useful (e.g.
given two changeset IDs you can look at a list of the changes between
them, whereas given two version numbers you can't do much).
> 3) You fire up the currently installed beta which you haven't run in a
> while, and just want to know what the hell you're running.
It's either the latest beta or not the latest one... in the latter case,
the dialog tells you it's not up to date. Do you really care _which_
out of date beta you're running? I'm willing to accept that you are; I
just want to understand why.
> Are you planning to carry this over to release builds? Are all security/bug
> fix releases going to report 5.0?
The security/bug fix release for 5.0 is 6.0, fwiw, unless there's a
zero-day.
I can't recall what the current version numbering plans for
zero-day-triggered releases are; last I checked there was some debate,
with a number of people saying they should in fact report 5.0 to websites.
> Well, there should be
I agree (for unrelated reasons). There's a bug on it; patches accepted
as usual. ;)
-Boris
Christian Legnitto
Yes, you are running 5. The changes on beta are minimal so you should not have to specify further. If for sone reason you need to, there's the about: page (I bet you never will)
> 2) Your are running two or more builds simultaneously side by side to trace
> how some behavior changed. Again it should be trivial to get the exact
> version from a running instance.
Shouldn't be any substantial changes between beta and the final release. It takes work to run two builds side by side, why is it too much work to type a local url? Again, if you need it the info is there in any case.
>
> 3) You fire up the currently installed beta which you haven't run in a
> while, and just want to know what the hell you're running.
Why? So you can see if you have the latest? Checking for updates will tell you that. You'll have an update to the latest version downloading in the background anyway. And if you are really curious, the about URL isn't going away...
> Are you planning to carry this over to release builds? Are all security/bug
> fix releases going to report 5.0?
We don't have point releases. If there are respin worthy fixes we need to take (high bar) they will be identified differently
>
>>
>>> That's a strawman, I did not ask about the UA, it can stay constant, but
>>> there is no justification for hiding the real version from the user.
>>
>> There is no infrastructure in place for showing different things to the
>> user.
>
> Well, there should be, if there are legitimate reasons for hiding the
> version from websites, there aren't for hiding it from the user.
>
You are looking at this the wrong way. Users shouldn't care about the version, only that they are running firefox. If they aren't on the latest they will soon be (and may already be without knowing once we get silent updates done). The version is an implementation detail to end users.
I don't see why this is controversial honestly. The data is there for those that need it and we have concrete engineering reasons for keeping the version the same between beta builds and release.
Additionally, in an ideal world the beta build would be tested, no issues found, and then released to the world byte for byte identical. If beta and release identified differently we would always need a rebuild, which can allow unexpected issues to creep in. It's not where we are at now but it is where we are striving to be.
al...@yahoo.com
> On 5/21/11 2:46 AM, al...@yahoo.com wrote:
>> That uri is random noise, a meaningful and useful version to the user is
>> something like the tag FIREFOX_5_0b2_RELEASE
>
> How about "current beta of Firefox 5"? The dialog does tell you that,
> fwiw.
Why don't you tag all your releases in source control as "current beta" and
see how useful that is?
>
>> Have you really never had a reason to identify and possibly communicate a
>> version of some software you're running?
>
> I have, but see below.
>
>> 1) You discover a possible problem in Fx or an extension. You want to
>> discuss the problematic behavior, it should be trivial to identify the
>> build
>> and communicate it it to others.
>
> To which others? If you're communicating it to _me_ for example, in my
> capacity as a someone working on Gecko, I don't care that much what
> version string is showing for you; I do care what code is running (and the
> changeset is the way to identify that).
When users discuss Fx and extension related issues with each other and
extension devs, identifying the Fx version is usually the first priority.
It's unreasonable to expect everyone to think in terms of changesets, which
unlike versions, really are an implementation detail. As long as software
is released in discrete builds, (advanced) users need to be able to identify
and disambiguate them. Versions get the job done well enough, as long as
they uniquely identify a build and increment (have an order), otherwise they
can be arbitrary.
>
> I grant that if you want to discuss this with people who are not dealing
> with the source you may want some other shorthand for particular builds.
> But what happens if we start doing daily updates on the beta channel?
> Should we end up with a b42 by the time it becomes final? It really
> doesn't make that much sense to rev a "version number" for every single
> change on the beta channel. I mean, I suppose we could do that, so you'd
> have a version number like 5.0b39 or 5.0.1.39 in Chrome-land, say. Is that
> really more useful for discussion than the changeset id?
Yes, incrementing ordered versions numbers, alphas, betas, rcs are well
established and understood concepts, changeset ids are gibberish in
comparison.
> guess you can immeditely tell which one is newer with this sort of
> notation....
>
>> 2) Your are running two or more builds simultaneously side by side to
>> trace
>> how some behavior changed. Again it should be trivial to get the exact
>> version from a running instance.
>
> In this case, once again, I think the changeset id is more useful (e.g.
> given two changeset IDs you can look at a list of the changes between
> them, whereas given two version numbers you can't do much).
>
>> 3) You fire up the currently installed beta which you haven't run in a
>> while, and just want to know what the hell you're running.
>
> It's either the latest beta or not the latest one... in the latter case,
> the dialog tells you it's not up to date. Do you really care _which_ out
> of date beta you're running? I'm willing to accept that you are; I just
> want to understand why.
>
>> Are you planning to carry this over to release builds? Are all
>> security/bug
>> fix releases going to report 5.0?
>
> The security/bug fix release for 5.0 is 6.0, fwiw, unless there's a
> zero-day.
>
> I can't recall what the current version numbering plans for
> zero-day-triggered releases are; last I checked there was some debate,
> with a number of people saying they should in fact report 5.0 to websites.
So you're going to report 5.0 to users as well? Showing the same version
for different builds defeats the point of versioning.
>
>> Well, there should be
>
> I agree (for unrelated reasons). There's a bug on it; patches accepted as
> usual. ;)
What's the bug?
>
> -Boris
Asa Dotzler
so late that the conversation was already long finished and the
resulting plan has been implemented and deployed.
So far you've added no new information and so there's really no value in
continuing here.
If you want more answers, please read up on earlier threads in this
group and m.d.planning as well as the various wiki pages and blogs.
Thanks for your interest, and your desire to help make Firefox easier
for people.
- A
Robert Kaiser
> Are you saying that b2 could become the release?
Yes. Unless we discover any bad issues in Beta testing, this is exactly
the code that will ship as the release.
We might do some further beta builds with crash fixes or other small
fixes for anything that's broken, but development for 5 has stopped and
this is the result. Again, if we don't find any crashes or other
glitches, we will ship exactly that code.
In terms of potential features, it actually was already complete five
weeks ago when it came to Aurora the first time. ;-)
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! :)
JP Rosevear
> al_9x, you're way late to this conversation. As a matter of fact, you're
> so late that the conversation was already long finished and the
> resulting plan has been implemented and deployed.
The rationale is documented:
http://mozilla.github.com/process-releases/draft/development_specifics/#versioning
-JP
--
JP Rosevear <j...@mozilla.com>
Mozilla