348066 - Make Lightning 0.3 available via extension update in Thunderbird after release

Status: RESOLVED FIXED

(Calendar :: Website, enhancement)

Description

[Stefan Sitter [:ssitter]]

In my oppinion it makes sense to make the Lightning 0.3 available via extension update in Thunderbird after release.

I have successfully updated Lightning 0.1 to 0.1+ using a local update.rdf file and the *.xpi was downloaded from http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-mozilla1.8/windows-xpi/lightning.xpi.

I will attach the update.rdf file so that it can be used as a template.

What is required to achieve this?
1) Put Lightning *.xpi to ftp server 
   --> that will be already done during release

2) Provide 3 different update.rdf file on Calendar homepage.
   --> Lightning 0.1 searches for updates on:

 http://www.mozilla.org/projects/calendar/lightning/WINNT_x86-msvc/update.rdf
 http://www.mozilla.org/projects/calendar/lightning/Linux_x86-gcc3/update.rdf
 http://www.mozilla.org/projects/calendar/lightning/Darwin_ppc-gcc3/update.rdf

em:updateLink in the template update.rdf file has to be updated to point to the specific win/linux/mac-ppc *.xpi location. The rest is the same for all.

Comment 1

[Stefan Sitter [:ssitter]]

Attachment: example update.rdf file

Comment 2

[Joey Minta]

Note that we also need release/nightly update channels here.

Comment 3

[Stefan Sitter [:ssitter]]

(In reply to comment #2)
> Note that we also need release/nightly update channels here.

Extension update does not know channel concept. If you want update for nightly builds you have to increase the version number for every nightly build, add the new version to the update.rdf file and upload the changed update.rdf to website.

Comment 4

[Joey Minta]

(In reply to comment #3)
> (In reply to comment #2)
> > Note that we also need release/nightly update channels here.
> 
> Extension update does not know channel concept. If you want update for nightly
> builds you have to increase the version number for every nightly build, add the
> new version to the update.rdf file and upload the changed update.rdf to
> website.
> 
I think we want an #ifdef in the rdf file we ship with lightning.  If we define it to be RELEASE, then it points to one set of update files, if we define it to NIGHTLY then it points to a differnt set of update files.

Comment 5

[Stefan Sitter [:ssitter]]

(In reply to comment #4)
I think nightly updates concept, the necessary changes to version number concept, the tinderbox scripts that create/publish the new update files, etc. should be discussed in another bug.

Maybe Simon can comment if the changes to the website to allow 0.1->0.3 update are feasible for our release time frame.

Comment 6

[Simon Paquet [:sipaq]]

The changes to the website can easily be done.

Comment 7

[Matthew (lilmatt) Willis]

I just verified the auto-update functionality works with our current Lightning builds.

Taking this.

Comment 8

[Matthew (lilmatt) Willis]

We still need to determine our delivery story for Lightning 0.3, meaning whether we to host it on addons.mozilla.org or not.

requesting blocking0.3

Comment 9

[Stefan Sitter [:ssitter]]

(In reply to comment #8)
So what decision have to be made:

1. Upload ltn builds to ftp server, to a.m.o or to both? This affects em:updateLink in update.rdf. Might be woth to discuss about Bug 331274 too.

2. Decide if future versions (including 0.3) should search for updates on a.m.o or calendar webpage (as now)? In first case install.rdf must be changed.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

While we would very much like this, if push comes to shove, we could live without it.  Furthermore, we can do this after the release happens.  Removing blocker status.

Comment 11

[Matthew (lilmatt) Willis]

This just landed on www.mozilla.org, and I tested it with WinXP.
It would be good to test on Linux and both Mac PPC an Mac x86, but this is FIXED