Opened 23 months ago

Closed 4 weeks ago

#25099 closed task (fixed)

Update nightly version number

Reported by: boklm Owned by: boklm
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm, tbb-update, TorBrowserTeam201911R
Cc: boklm, mcs, brade, ln5, tbb-team Actual Points:
Parent ID: #18867 Points: 1
Reviewer: Sponsor:

Description

In order to be able to update Tor Browser nightly builds each day, we need each build to have a different version number.

Currently the version for nightly builds is set to tbb-nightly. I think we could change it to the current day with something like 2018.01.31.

Child Tickets

Change History (18)

comment:1 Changed 23 months ago by mcs

For the updater to work correctly, the version number needs to conform to Mozilla's standard format (and newer releases need to have a higher number). See: https://developer.mozilla.org/en-US/docs/Mozilla/Toolkit_version_format

I am not sure what Mozilla uses for nightly Firefox builds, but maybe we can do something similar.

comment:2 in reply to:  1 ; Changed 23 months ago by mcs

Replying to mcs:

I am not sure what Mozilla uses for nightly Firefox builds, but maybe we can do something similar.

Apparently they use an alpha version number, e.g., appVersion="60.0a1" and rely on the fact that they change the buildID for each nightly build, e.g., buildID="20180131100706".

comment:3 in reply to:  2 ; Changed 23 months ago by boklm

Replying to mcs:

For the updater to work correctly, the version number needs to conform to Mozilla's standard format (and newer releases need to have a higher number). See: https://developer.mozilla.org/en-US/docs/Mozilla/Toolkit_version_format

Thanks for the link. If I understand it correctly, it seems a version number like 2018.01.31 would conform to this standard format. We could also include the alpha version number in addition to the date, like 8.0a1.2018.01.31.

Replying to mcs:

Replying to mcs:

I am not sure what Mozilla uses for nightly Firefox builds, but maybe we can do something similar.

Apparently they use an alpha version number, e.g., appVersion="60.0a1" and rely on the fact that they change the buildID for each nightly build, e.g., buildID="20180131100706".

I think it would be possible for us to do it like this, but would require some changes in our tools:

  • change the mar file names to include the buildID number
  • change the script we use to generate incremental mars to be able to do it from two builds that have the same version number but a different buildID
  • change the script we use to generate XML update responses to handle URLs with a buildID

I think updating the version number only would require less changes. So I'm wondering if there is some other reason that would still make us prefer doing it with the buildID like Mozilla.

comment:4 in reply to:  3 Changed 23 months ago by mcs

Replying to boklm:

Replying to mcs:

For the updater to work correctly, the version number needs to conform to Mozilla's standard format (and newer releases need to have a higher number). See: https://developer.mozilla.org/en-US/docs/Mozilla/Toolkit_version_format

Thanks for the link. If I understand it correctly, it seems a version number like 2018.01.31 would conform to this standard format. We could also include the alpha version number in addition to the date, like 8.0a1.2018.01.31.

I think that would work.

Replying to mcs:

Replying to mcs:

I am not sure what Mozilla uses for nightly Firefox builds, but maybe we can do something similar.

Apparently they use an alpha version number, e.g., appVersion="60.0a1" and rely on the fact that they change the buildID for each nightly build, e.g., buildID="20180131100706".

I think it would be possible for us to do it like this, but would require some changes in our tools:

  • change the mar file names to include the buildID number
  • change the script we use to generate incremental mars to be able to do it from two builds that have the same version number but a different buildID
  • change the script we use to generate XML update responses to handle URLs with a buildID

I think updating the version number only would require less changes. So I'm wondering if there is some other reason that would still make us prefer doing it with the buildID like Mozilla.

I don't know of any reason to favor one approach over another, except doing it like Mozilla does might make it less likely that things will break for us in the future. But that is only a theoretical concern, and if our nightly updates break it would not be the end of the world.

comment:5 Changed 11 months ago by gk

Keywords: tbb-updater added

comment:6 Changed 10 months ago by gk

Keywords: tbb-update added; tbb-updater removed

Renaming keyword to make it a bit broader

comment:7 Changed 3 months ago by gk

Keywords: TorBrowserTeam201909 added

comment:8 Changed 3 months ago by gk

Points: 1

comment:9 Changed 3 months ago by pili

Keywords: TorBrowserTeam201910 added

comment:10 Changed 3 months ago by pili

Keywords: TorBrowserTeam201909 removed

comment:11 Changed 2 months ago by boklm

As doing it the same way as Mozilla requires a lot of changes, I think we can start with the more simple solution of using a version number that includes the date, and do it differently if we see problems with that.

I started working on a patch changing the version number to tbb-nightly.$year.$month.$day (which I think conform to Mozilla's standard format for version numbers):
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25099&id=2f38beae42a9f2495fbf4f5cecddfe2286ab1dd0

I did not try doing a build with this patch yet.

comment:12 Changed 6 weeks ago by pili

Keywords: TorBrowserTeam201911 added; TorBrowserTeam201910 removed

Moving tickets to November 2019

comment:13 Changed 5 weeks ago by boklm

Keywords: TorBrowserTeam201911R added; TorBrowserTeam201911 removed
Status: newneeds_review

comment:14 in reply to:  13 ; Changed 5 weeks ago by boklm

Replying to boklm:

There is a patch for review in branch bug_25099_v4:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25099_v4&id=9d0fd923bc0befa0533fbdf5ddfa57f7e7be53cc

Currently we put the nightly builds in directory nightly/$year-$month-$day. Now that the version is changing every day, a possible simplification would be to put it inside nightly/$torbrowser_version.

comment:15 Changed 5 weeks ago by pili

Cc: tbb-team added
Owner: changed from tbb-team to boklm
Status: needs_reviewassigned

Assigning more tickets to boklm for the next few months

comment:16 in reply to:  14 Changed 4 weeks ago by boklm

Keywords: TorBrowserTeam201911 added; TorBrowserTeam201911R removed
Status: assignedneeds_revision

Replying to boklm:

Replying to boklm:

There is a patch for review in branch bug_25099_v4:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25099_v4&id=9d0fd923bc0befa0533fbdf5ddfa57f7e7be53cc

Currently we put the nightly builds in directory nightly/$year-$month-$day. Now that the version is changing every day, a possible simplification would be to put it inside nightly/$torbrowser_version.

Doing that will also simplify the generation of incremental mars, as the gen_incrementals script currently expects the directory name to be the same as the version number. I will post a new revision of the patch doing that.

comment:17 Changed 4 weeks ago by boklm

Keywords: TorBrowserTeam201911R added; TorBrowserTeam201911 removed
Status: needs_revisionneeds_review

There are two patches for review in branch bug_25099_v10:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_25099_v10&id=0f019cf3aa17c6b77bb8126a9c4bdf47886238cb

One of them remove the alpha_nightly target, for simplification, as I think it was not really used. The other sets the version to tbb-nightly.$year.$month.$day, and also use that version number as the directory name in nightly/.

comment:18 Changed 4 weeks ago by gk

Resolution: fixed
Status: needs_reviewclosed

Looks good to me. Merged to master (commit da23c8cd79dab16f1848cacde60be0588c0d59a5).

Note: See TracTickets for help on using tickets.