299930 - Need nsIXULAppInfo.geckoVersion

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect, P1)

Description

[Benjamin Smedberg]

We need nsIXULAppInfo.geckoVersion which is formatted like an extension manager
version # (1.7+, currently).

Comment 1

[Benjamin Smedberg]

targeting b4

Comment 2

[Benjamin Smedberg]

Attachment: Add nsIXULAppInfo.platformVersion, rev. 1

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 188553 [details] [diff] [review]
Add nsIXULAppInfo.platformVersion, rev. 1

I'm not really familiar enough with this stuff to say; over to darin?

Comment 4

[Darin Fisher]

Comment on attachment 188553 [details] [diff] [review]
Add nsIXULAppInfo.platformVersion, rev. 1

perhaps s/version/appVersion/ to match appBuildID?  maybe vendor and name
should be appVendor and appName as well?  oh wait... this is nsIXULAppInfo...
maybe the platform fields should be on nsIXULRuntime instead then?

Are we moving away from the 1.8b3 notation to the 1.7+ notation for the
platform?

MILESTONE_EM seems like a funny name.  i figure EM means extension manager,
right?	i guess this name works.. not sure what else we might call it.

Comment 5

[Benjamin Smedberg]

I did not want to change .version to .appVersion because of significant usage in
existing code.

I thought about putting this on nsIXULRuntime but I intend to freeze
nsIXULAppInfo immediately and do not intend to freeze nsIXULRuntime any time
soon. I think that nsIXULAppInfo is a decent place to hang this data.

Comment 6

[Darin Fisher]

Comment on attachment 188553 [details] [diff] [review]
Add nsIXULAppInfo.platformVersion, rev. 1

I can relate to the pain that an interface change would be, so ok.  I guess we
live with it.  It's a bit awkward to have "app" prefix only 1 of the 4
application attributes, and it's also odd to have platform attributes on an
interface whose name describes the application, but ok.. sure ;-)

Comment 7

[Benjamin Smedberg]

Fixed on trunk for 1.8b4.