It would be handy to be able to get the current version of the addon easily, eg: var version = require("self").version; The use case suggested today in IRC was so that code can be run when a user upgrades to a newer version of the add-on. This code might need to be sufficiently fine-grained when dealing with data schemas / formats. There are probably other use cases.
I poked around looking at a low-level way to get access to the version, the could would look something like this: https://builder.addons.mozilla.org/addon/1013461/revision/19/ In builder there is no way to find the current add-on based on self.id, I think due to the way add-ons are run in the builder environment. This is true also of cfx run, making this approach pretty hard to test without building first.
Update: building an xpi does reveal the correct id and version through AddonManager: https://builder.addons.mozilla.org/addon/1013461/revision/21/
console.log(packaging.options.metadata[packaging.options.name].version); This works for me in Builder, though I agree that there should be a shorter way to get this information...
Plus, bug 596077 will take away the packaging global...
The builder example is updated, but yes, once bug 596077 is fixed this'll all fail.
require("self").version is the right way to do this. I'll throw together a patch. Any thoughts on whether ".version" is the right name, or if we should use ".addOnVersion" or something? (i.e. are there versions of anything else that we might want to provide through require("self") which might compete for this name?)
Would the SDK version number be useful to have available?
Following on from the previous 2 comments: self.addOnVersion self.sdkVersion Wes: do you have a use case for needing the current SDK version in code? And is there no way the reported SDK version would change in some way that would break an add-on if it did things conditionally based on a specific sdk version?
(In reply to Jeff Griffiths from comment #8) > Following on from the previous 2 comments: > > self.addOnVersion > self.sdkVersion > > Wes: do you have a use case for needing the current SDK version in code? And > is there no way the reported SDK version would change in some way that would > break an add-on if it did things conditionally based on a specific sdk > version? I can't think of one personally. Was just going off of the "what else could we provide that would compete for this name" bit. SDK's the only other versioned thing I can think of that's exposed through there...
After chatting with Warner on IRC, it seems that we have future plans to potentially 'repack' add-ons in-place on AMO, meaning that if this is done, these add-ons would have a different skd version. Quothe Brian: warner: I'm uncertain about providing self.sdkVersion .. I can only imagine bad ways to use it. Given that, I'm not opposed to: self.version ...as it is semantically correct *and* intuitive, IMO.
Created attachment 553944 [details] [diff] [review] add 'name', 'version', and 'sdkVersion' to require("self") this adds all three new properties. I wouldn't mind being talked out of including 'sdkVersion' :).
OS: Mac OS X → All
Priority: -- → P2
Hardware: x86 → All
Target Milestone: --- → 1.2
Comment on attachment 553944 [details] [diff] [review] add 'name', 'version', and 'sdkVersion' to require("self") r+ on self.version and self.name; r- on self.sdkVersion, given the current ratio of good/bad things anyone can think of using it for. We can always add it later if the ratio changes. Thus r=myk without self.sdkVersion.
Attachment #553944 - Flags: review?(myk) → review+
Landed, in https://github.com/mozilla/addon-sdk/commit/034255e38b845283f59aa3de959b5674b9210e21 , without self.sdkVersion
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.