180383 - GRE libs versions need to change on every build

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Sean Su]

None of the libraries that make up GRE have any string version.  This version
info is an added step to make sure that embedded apps can detect exactly which
version of GRE is installed on a system.

Using just the windows registry to determine the version of GRE installed is not
accurate enough as there are many builds between releases.

Comment 1

[Chak Nanga]

Sean...please note that the current libraries which are part of the GRE package
are the ones which Mozilla/Netscape package - they do not have any version info.
either.

When someone works on getting version strings into those dlls GRE will use that
info. instead of looking in the registry.

Until then someone else should take this bug.

Comment 2

[hacker formerly known as [e-mail]]

Define string version.  Aki added support for versioning info to the win32 libs
& exes awhile ago.  The Version tab of the Properties dialog should show the
version number.

Comment 3

[Sean Su]

actually, I do see 'File Version' strings (in the Version tab) for xpcom.dll and
gkgfx.dll.  They are all 1.3.0.0.

My bad.  I had thought that only Netscp.exe (and mozilla.exe) was versioned, but
it turns out that it is 0.0.0.0.  Is this normal for a daily build?

closing bug as invalid because the GRE files are already properly versioned.

Comment 4

[Sean Su]

I'm reopening because the file version string for the gre files are all set to
1.3.0.0.  We need it to be more granular, like: 1.3.0.[build id], where [build
id] can be the generic build date like the one used for mozilla.

Comment 5

[Aki Sasaki]

this is how all the mozilla exes and dlls are versioned... do you want gre to be
different?

Comment 6

[Sean Su]

you're misunderstanding me.  Currently, the mozilla files are versioned with the
following windows native fileversion: 1.3.0.0.  It needs to be 1.3.0.[build id],
where the [build id] for today as an example is 2002112508.  The [build id] is
what's missing right now.

Comment 7

[hacker formerly known as [e-mail]]

Here's a silly question.  Is that 4th field big enough to store a buildid ?  I
thought that they were 16-bit ints?

Comment 8

[Sean Su]

you're right.  they are only 16 bits each under windows.  it'll have to be some
smaller sequential number then.

Comment 9

[Doug Turner (:dougt)]

i belive that the premise that all of the libraries in the GRE need to be
versioned for the GRE to work is flawed.  

I agree that our libraries should be versioned, but this task is orthogonal to
the gre work.  

chak, maybe you should dup this against an existing bug or mark as wontfix/invalid.

Comment 10

[Daniel Veditz [:dveditz]]

Not all the libraries need to be versioned, but there must be at least one that
the installer can look at (I think the versioning mechanism extends to all the
dlls so it might as well be all). The version must include the daily build
number or some other incrementing value so that the nightly installers will
always install the latest build. Failing to do so will result in bad Mozilla
testing and lots of bogo-bugs.

I can think of a couple of alternatives, but they are more on-going work and
much more at risk of update failure; I strongly recommend fixing the versioning.
For the record, however, we could

1) For nightly builds record the "supersede" version (not the registry keys
which would remain the correct version) as one higher than the actual version to
be installed (i.e. 1.4.0.0 when installing 1.3b). It will always look like we've
got a newer version to install and will always overwrite it. Downside: another
thing we have to remember to change for each release branch, and in the scans to
change "currentversion" to "next version" we won't match on something already
being the next version so there's extra room for error. I'm not sure branches
will work quite right, either.

2) Add a flag in the install config.ini that basically says to force install the
GRE. Again another thing to remember to change on release branches, will have to
be added to the checklist. The sad thing is that this is what the supersede
functionality is already intended to do, but it doesn't work if we only have the
option of superseding based on 13-week milestone chunks.

The funny thing is that the whole GRE mechanism assumes the client changes more
often than the GRE, but for Mozilla it's actually the opposite given the current
developer resources.

As to the actual version, yeah the 16-bit limit per part sucks but it's not a
fatal problem. For example we could chop the buildID arbitrarily in two, such as
1.3.0301.0508 (yymm.ddhh -- no more y2k worries, plus it only has to be unique
within the "1.3" part).

Whatever we do we only have to write the code once and it'll work thereafter
without having to worry about it every release.

This is a build issue -> release team

Comment 11

[Brian 'netdragon' Bober]

I assume by comment #1 that fixing bug 50627 using the framework laid out in 
bug 23560 will allow this bug to be fixed. There is a Mozilla versioning META 
bug 80613 so that its easier to find all the info people need for versioning 
and don't duplicate efforts.

Comment 12

[Michael Buckland]

Discussed in edt.  Plussing.  Chris, please target appropriate milestone.

Comment 13

[Doug Turner (:dougt)]

Attachment: patch

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 113144 [details] [diff] [review]
patch

sr=dveditz
a=dveditz on behalf of drivers

Comment 15

[Doug Turner (:dougt)]

the patch i just checked in allows the check for a local GRE without the enduser
doing anything special.

Comment 16

[Daniel Veditz [:dveditz]]

Doug's patch fixes a different problem and doesn't close this bug -- we still
need versions so we can supersede correctly. It possibly lowers the  urgency.

Comment 17

[hacker formerly known as [e-mail]]

Attachment: add buildid file version info

Comment 18

[Aki Sasaki]

Comment on attachment 113157 [details] [diff] [review]
add buildid  file version info

this works as long as mozilla milestones are only major.minor... which i assume
will be the case.

Comment 19

[Jon Granrose]

Probably won't need x.y.z versions again til 2.0, and if we hold schedule,
that's about 2 years away...  of course if mozilla.org decides to make something
sooner a major ongoing branch in place of 1.0, we'll have to address this then.

Comment 20

[hacker formerly known as [e-mail]]

Attachment: fix x.y.z milestones

x.y.z milestones shouldn't be an issue as we can substitute the build id for z.
 milestone x.y.z should always be older than milestone x.y.z++ and the build id
should reflect that. 

I did have to modify the script to only grab x & y though for the
productversion & fileversion.  The full milestone & build id are still stored
in the informational string fields.  I also had to move another digit of the
buildid into the 3rd field to avoid the rollover problem.

Comment 21

[Sean Su]

Comment on attachment 113172 [details] [diff] [review]
fix x.y.z milestones

r=ssu

Comment 22

[Asa Dotzler [:asa]]

Is this critical to the 1.3 releases? Can we hold it until 1.4alpha?

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 113172 [details] [diff] [review]
fix x.y.z milestones

It seems like this is something we might need if we do a 1.3.1, right?	In that
case, I think we're better off having it in now so we know if there are
problems with it.  Plussing (approval1.3b+) on that basis, but please let me
know if that's not the case.

Comment 24

[hacker formerly known as [e-mail]]

Patch has been checked in.