Closed
Bug 458255
Opened 16 years ago
Closed 13 years ago
need update snippets for lightning nightly builds
Categories
(Calendar :: Build Config, defect, P1)
Calendar
Build Config
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 322522
People
(Reporter: dmosedale, Unassigned)
Details
We need to have update snippets and a lightning nightly channel so that folks install a nightly once, and get nightly updates thereafter. I haven't set a target milestone on this, but it seems like it would be worthwhile to have Lightning nightlies that work with 3.0a3 not too long after it ships.
Note that running with Lightning nightlies and Tb nightlies might well involve restarting twice a day, which would be annoying. If so, we may want to punt and just do parallel Tb and Tb+Ltn builds, but carefully set expectations about what we have and haven't committed to ship.
Reporter | ||
Comment 1•16 years ago
|
||
Setting high priority on this, as drivers needs to be able to live on the hg tip in order to have a good feel for what needs to be done to get calendar into shipping shape (ship-shape?).
Flags: blocking-thunderbird3+
Priority: -- → P1
Target Milestone: --- → Thunderbird 3.0b1
Comment 2•16 years ago
|
||
See also Bug 322522 on this topic.
In the meantime you might want to check out the Lightning Nightly Updater (Unofficial) extension: https://addons.mozilla.org/thunderbird/addon/4623
Comment 3•16 years ago
|
||
Since this is an extension, the current update mechanism (.mar) will not work. What we'd need instead is the nightlies generating a update.rdf that the nightly extensions would pinging (from bug 322522 comment #1).
I think I could somewhat easily generate that update.rdf and upload it as part of the nightly builds. The extension itself needs to know it should pull from there, however, and I don't know how that would work.
If somebody can show me what an update.rdf should be loooking like (or better, make generating it part of the build step, for instance).
As for making sure the lightninig.xpi we end up packaging know where to ping for updates, I am sure calendar folks would know how to do that. Pointers?
Reporter | ||
Comment 4•16 years ago
|
||
A .mar can't handle embedded extensions? If that's true, how did we keep DOMi updated in the old Firefox nightlies?
As far as the XPI goes, <http://developer.mozilla.org/en/Extension_Versioning,_Update_and_Compatibility> has the details on how to set the update URL for the XPI.
Comment 5•16 years ago
|
||
(In reply to comment #4)
> A .mar can't handle embedded extensions? If that's true, how did we keep DOMi
> updated in the old Firefox nightlies?
I think gozer probably meant a .mar can't handle extension updates outside of the application package.
Firefox had the extension embedded in the application package, so the .mar just covered that as well (this is how SeaMonkey currently works as well).
Reporter | ||
Comment 6•16 years ago
|
||
The main reason to use a .mar, I assume, would be if we wanted to do it all as a single package in order to avoid restart-twice lossage, if such a thing exists.
Comment 7•16 years ago
|
||
Correct me if I am wrong, but even if it was possible to do a lightning .mar, that wouldn't be a thunderbird .mar, so how would thunderbird know to pull that update, and not the thunderbird nightly .mar ?
All in all, I don't suppose I know everything there is to know about how the update system works ;-)
Somebody who knows more needs to figure out /how/ lightning nightly XPIs should be updated. Once that's known, I can figure out how to make it so.
Comment 8•16 years ago
|
||
(In reply to comment #6)
> The main reason to use a .mar, I assume, would be if we wanted to do it all as
> a single package in order to avoid restart-twice lossage, if such a thing
> exists.
The only way we can do that at the moment is to package Lightning within Thunderbird. Unless we drastically extend the update system, which I don't think we want to do because I believe this is only short-term updates we're discussing about.
Reporter | ||
Comment 9•16 years ago
|
||
Mark: that is what I was trying to suggest, albeit not very clearly. Why would this require any extension of the update system at all, since this presumably happened for quite some time with Firefox and DOMi?
Comment 10•16 years ago
|
||
(In reply to comment #9)
> Mark: that is what I was trying to suggest, albeit not very clearly. Why would
> this require any extension of the update system at all, since this presumably
> happened for quite some time with Firefox and DOMi?
There would be no update required to the extension system (just to packages file and whatever tinderbox config that we need).
We would however want to consider how it gets displayed to the user, there are various issues with installing extensions with existing versions pre-installed, see https://wiki.mozilla.org/ChatZilla:Suiterunner for a discussion.
Reporter | ||
Comment 11•16 years ago
|
||
Gozer: if you could update this bug with current status, that'd be much appreciated, as a bunch of driving work depends on it. Thanks!
Comment 12•16 years ago
|
||
Current status as discussed on #calendar this morning:
Using Lightning Nightly Updater (see comment #2) is most likely good enough to unblock drivers.
Long term, the solution moving toward integrated builds will be to generate Thunderbird installers with Lightining included, and use the normal .mar update mechanism for the nightly builds.
Updated•16 years ago
|
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b2
Comment 14•16 years ago
|
||
Passing over to Calendar/Build Config to get it on the correct radar.
Assignee: gozer → nobody
Flags: blocking-thunderbird3-
Product: Thunderbird → Calendar
QA Contact: build-config → build
Target Milestone: Thunderbird 3.0b2 → ---
Comment 15•13 years ago
|
||
Work is being done in the following bug:
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•