458255 - need update snippets for lightning nightly builds

Status: RESOLVED DUPLICATE of bug 322522

(Calendar :: Build Config, defect, P1)

Description

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

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?).

Comment 2

[Stefan Sitter [:ssitter]]

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

[Philippe M. Chiasson (:gozer)]

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?

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

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

[Mark Banner (:standard8)]

(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).

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

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

[Philippe M. Chiasson (:gozer)]

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

[Mark Banner (:standard8)]

(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.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

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

[Mark Banner (:standard8)]

(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.

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

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

[Philippe M. Chiasson (:gozer)]

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.

Comment 13

[David Ascher (:davida)]

Doesn't block tb3.

Comment 14

[Philippe M. Chiasson (:gozer)]

Passing over to Calendar/Build Config to get it on the correct radar.

Comment 15

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Work is being done in the following bug: