I _think_ this probably just requires that we set the URL in install.rdf correctly, but we may also need a bit of the channel infrastructure in place.
Note that we're probably going to want the nightly builds to have a different update channel than the release builds, so it may be that this checkin should only go in along with the checkins that switch to release version numbers, and then be immediately backed out post-release along with those version number checkins.
Created attachment 213958 [details] [diff] [review] install.rdf patch, v1 This temporarily disables Firefox support as discussed on IRC, since that's not really ready for end-users. It also makes a bunch of other tweaks in order for tomorrows build to be a release candidate.
Created attachment 213962 [details] [diff] [review] install.rdf patch, v2 Tweaked as per IRC discussion.
Comment on attachment 213962 [details] [diff] [review] install.rdf patch, v2 woohoo! release candidate! r=jminta
(In reply to comment #5) > woohoo! release candidate! Great! Two small nits: Using already defined @BUILD_ID@ for build date in install.rdf would have been same results with less pain and without red tinderbox ;-) Updating extension results in displayed message "An error occurred while trying to find updates for Lightning". Reason is that the extension manager tries to parse the 404 html error page as update manifest file. Error: mismatched tag. Expected: </link>. Source File: http://www.mozilla.org/projects/calendar/lightning/Linux_x86-gcc3/update.rdf Line: 14, Column: 3 Source Code: </head>--^ on win it's http://www.mozilla.org/projects/calendar/lightning/WINNT_x86-msvc/update.rdf that fail)