433929 - Automatically increment the weave version

Status: RESOLVED INVALID

(Firefox :: Sync, defect, P2)

Description

[Dan Mills [:thunder]]

There is some code already to pull part of the version from `hg tip`.  But we don't consistently use this everywhere and on all platforms.  We should, so that automatic builds via buildbot can have different versions without relying on pull dates.

Bonus points if this behavior can be modified or overridden for release builds, where we might not want the hg revision number in the version.

Comment 1

[Chris Beard]

moving to 0.3

Comment 2

[Dan Mills [:thunder]]

These bugs need to be triaged, removing 0.3 milestone setting.

Comment 3

[Igor Velkov]

Attachment: includes hg tip id into version number

add hg tip id into version number showed in add-on manager and to filename.
Affect only dev builds.

patch for hg tip f110fbd01424

Comment 4

[Igor Velkov]

Attachment: includes hg tip id into version number r2

Now version with tip applies only to filename and version displayed in add-ons manager of dev builds.

Comment 5

[Dan Mills [:thunder]]

Myk, we had a discussion on versioning for snapshots, but I don't remember the details.  Do you?

Igor, hg versions don't really work, because they are repository-specific.  The bigger hash is not, but that one is not a number, so it doesn't work as a version.

Comment 6

[Igor Velkov]

It's not comparable, but main part of id equal at least in my and mozilla's repository. And with that patch possible to keep some versions of different revisions, and link it with hg by id.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

It looks like this patch is using the version (In reply to comment #5)
> Myk, we had a discussion on versioning for snapshots, but I don't remember the
> details.  Do you?

As you note, it's problematic to use the revision number (i.e. the auto-incrementing decimal number that uniquely identifies changesets within a repository), since that varies across repositories, and it's also problematic to use the changeset ID (i.e. the hexadecimal number that uniquely identifies changesets across repositories), since toolkit version string part subparts cannot generally be both alphabetical and numeric due to the way the version parser parses version parts into subparts.

However, there is a way to include the changeset ID in the string: make it be the fourth subpart of a version string part, since the parser stops identifying subpart boundaries after the third subpart and slurps the rest of the version part into the fourth subpart field.

In other words, given the following version string:

  0.3.2foo3bar4x5y6z7

The third version part (2foo3bar4x5y6z7) will get broken into the following four subparts:

  1: 2
  2: foo
  3: 3
  4: bar4x5y6z7

Which means as long as you ensure that the first three subparts always cause versions to compare with each other correctly, f.e. by including a ISO 8601-ish all-numeric date/time stamp in one of the first three subparts, you can put anything into the fourth subpart, like the changeset ID.

So a development version of Weave between the current version 0.3.2 and the next version 0.3.3 could be something like 0.3.3d[date]r[changeset ID], f.e. 0.3.3d200905280840r8891aaf91425, or 0.3.2.99d[date]r[changeset ID].

Currently, the latest development version of Snowl is using the version string 0.3pre1d200904092229.  I don't recall right now why I'm using this particular format, though.

Comment 8

[Dan Mills [:thunder]]

Thanks Myk!  I remember our discussion now.  The reason you settled on "0.3pre1d[date]" (IIRC) is that you thought "0.2.99d[date]" would not be as easy to understand to your current snapshot users.

"pre" still gives me the shivers, so I propose for Weave that we do:

0.<major>.<minor> - release builds
0.<major>.99d<date> - snapshots

I'm debating whether it makes sense to add the hg (hex) revision string as well.  It would make the version quite long, but if there were two snapshots in the same day it would be quite useful.

If we do add the revision, we should also (in a followup bug) make sure 'make' leaves no modified files (I'm lookin' at you, platform dir!), and then add a string to the version like 'plus' if there are locally modified files.  e.g.:

0.<major>.99d<date>r<rev>plus

Would mean someone checked out <rev>, modified it, and built a xpi on <date>.

Comment 9

[Igor Velkov]

Attachment: add build 'dxpi' option for building xpi with uncompressed chrome

I use this patch to have a weave tree plain inside profile. It makes me possible to tweak source code and try it simply with reload browser, shorten "edit-build-install-test" cycle to "edit-test".

Comment 10

[Dan Mills [:thunder]]

(In reply to comment #9)
> Created an attachment (id=380197) [details]
> add build 'dxpi' option for building xpi with uncompressed chrome
> 
> I use this patch to have a weave tree plain inside profile. It makes me
> possible to tweak source code and try it simply with reload browser, shorten
> "edit-build-install-test" cycle to "edit-test".

This is really outside the scope of this bug... :-)

Also, I think your use-case is better served by putting a text file in your extensions dir that contains the path to the weave sources, and merely doing 'make build'.  There is no need to build an xpi with uncompressed sources.

Comment 11

[Igor Velkov]

Heh.
My problem is my build env is headless linux, and my browser located on another computer with windows. That's the case :)

Comment 12

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #8)
> I'm debating whether it makes sense to add the hg (hex) revision string as
> well.  It would make the version quite long, but if there were two snapshots in
> the same day it would be quite useful.

Including the hour and minute in the timestamp, i.e. 200905281255 instead of just 20090528, helps in the case of multiple builds on he same day.

Nevertheless, even so it seems like the hex changeset ID is useful to have to definitively identify the version of the code, since you can build today from a tree pulled last month.


> If we do add the revision, we should also (in a followup bug) make sure 'make'
> leaves no modified files (I'm lookin' at you, platform dir!), and then add a
> string to the version like 'plus' if there are locally modified files.

I like this idea.

Comment 13

[Wladimir Palant]

Comment on attachment 379940 [details] [diff] [review]
includes hg tip id into version number r2

> +  revid   := $(shell hg tip --template '{node|short}')

As mentioned in bug 496563, this should use "hg id" command rather than "hg tip". Unfortunately, "hg id" doesn't accept templates and will always return a newline at the end - this one needs to be removed.

Comment 14

[Dan Mills [:thunder]]

Comment on attachment 379940 [details] [diff] [review]
includes hg tip id into version number r2

I'm not in the loop for Sync stuff anymore, clearing review.  You can ask for review from the Sync team if you still want this.

Comment 15

[Dan Mills [:thunder]]

Comment on attachment 380197 [details] [diff] [review]
add build 'dxpi' option for building xpi with uncompressed chrome

Chris is not in the loop for Sync stuff anymore, clearing review.  You can ask for review from the Sync team if you still want this.