Update nightly version number

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.

added TorBrowserTeam201911R component::applications/tor browser owner::boklm parent::18867 points::1 priority::medium resolution::fixed severity::normal status::closed tbb-rbm tbb-update type::task labels

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.

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".

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.

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.

Trac:
Keywords: N/A deleted, tbb-updater added

Renaming keyword to make it a bit broader

Trac:
Keywords: tbb-updater deleted, tbb-update added

Trac:
Keywords: N/A deleted, TorBrowserTeam201909 added

Trac:
Points: N/A to 1

Trac:
Keywords: N/A deleted, TorBrowserTeam201910 added

Trac:
Keywords: TorBrowserTeam201909 deleted, N/A added

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.

Moving tickets to November 2019

Trac:
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201911 added

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

Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201911 deleted, TorBrowserTeam201911R added

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.

Assigning more tickets to boklm for the next few months

Trac:
Status: needs_review to assigned
Owner: tbb-team to boklm
Cc: boklm, mcs, brade, ln5 to boklm, mcs, brade, ln5, tbb-team

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.

Trac:
Status: assigned to needs_revision
Keywords: TorBrowserTeam201911R deleted, TorBrowserTeam201911 added

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/.

Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam201911 deleted, TorBrowserTeam201911R added

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

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

changed time estimate to 8h

mentioned in issue #32788 (moved)

moved to tpo/applications/tor-browser#25099 (closed)

mentioned in issue tpo/applications/tor-browser#32788 (closed)