Closed Bug 440022 Opened 16 years ago Closed 16 years ago

ensure that Lightning doesn't have empty min/maxVersion in install.rdf


(Calendar :: Lightning Only, defect)

Not set


(Not tracked)



(Reporter: kairo, Assigned: kairo)




(1 file, 1 obsolete file)

When trying to build Lightning with mozilla-central, I noticed that its install.rdf ends up with <em:minVersion> and <em:maxVersion> tags for the product that I was not building at the moment, as we don't have the central configure define all the _VERSION variables any more.
The real problem with that is that EM does not activate Lighting and always tells us it requires a restart to activate (but doesn't actually activate it with that restart) when it encounters such an empty version field for any application listed in the install.rdf (even when it's not the one we are installed in).
Everything works fine though if the [min|max]Version tags are missing completely, so I figured we only should put them in there when the relevant _VERSION is defined, just to be on the safe side.
This patch makes us only use the _VERSION vars if they are set. The case when SEAMONKEY_VERSION is missing (normal Thunderbird build under Gecko 1.9.1) is pretty easy, the case when THUNDERBIRD_VERSION is missing (normal SeaMonkey build under 1.9.1) has been tested well by me and was the cause why I even came across this bug.

I think it's worth taking this fix even if we might decide to define those variables for the default builds so that the install.rdf ends up being complete usually. This fix makes us create an install.rdf that at least works with one application when we somehow lose the version definition for the other (as it's currently the case in my setup described in the wiki doc).
Assignee: nobody → kairo
Attachment #325575 - Flags: review?(daniel.boelzle)
Attachment #325575 - Flags: review?(daniel.boelzle) → review?(ause)
Blocks: 442566
Summary: make Lightning still work when not all _VERSION vars are defined during build → ensure that Lightning doesn't have empty min/maxVersion in install.rdf
After discussion with Standard8, this patch is more sane. We're now fetching those version values ourselves (in cvs, we always pull the version.txt files from other projects with, in the new repo, we always pull all Thunderbird and SeaMonkey files, so those always succeed) and completely lose the dependency on the build system providing any of those version numbers.

The Firefox one will probably only work in the new repository, but I figured as long as we have that build option for install.rdf, we should support it in as well.
Attachment #325575 - Attachment is obsolete: true
Attachment #327336 - Flags: review?
Attachment #325575 - Flags: review?(ause)
Attachment #327336 - Flags: review? → review?(ause)
Attachment #327336 - Flags: review?(ause) → review+
Checked into 1.8 branch and cvs trunk.
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.9
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.