Update the update_responses script for the 4.5 soft launch

To allow releasing a new stable version without advertising it in the updater, we need an option in the config.yml file to say that the version is up-to-date and does not need to be downgraded to the version currently advertised in the updater.

I am attaching to this ticket a patch to add the 'no_update_for' option to the config.yml file. If we want to do a soft launch for 4.5, we will need to add the following lines to config.yml:

no_update_for:
    release:
        - 4.5

added TorBrowserTeam201504R component::applications/tor browser owner::tbb-team priority::medium resolution::wontfix status::closed tbb-4.5-alpha type::enhancement labels

Trac:
0001-Bug-15670-add-support-for-the-no_update_for-option-i.patch

Trac:
Keywords: TorBrowserTeam201504 deleted, TorBrowserTeam201504R added
Status: new to needs_review

I think this looks OK. At the point in time we want people running 4.0.8 to upgrade to 4.5, we would just remove the "no_update_for" directive and regenerate the update responses files?

Trac:
Keywords: N/A deleted, tbb-4.5-alpha added

Replying to mcs:

I think this looks OK. At the point in time we want people running 4.0.8 to upgrade to 4.5, we would just remove the "no_update_for" directive and regenerate the update responses files?

That would be one option, yes. Applied to master in commit 7d7faa30b4443f0cc76474738a36fd3f45e875f4. Do we really think this were necessary if we would just avoid updating the update responses files in the first place and deliver the updated ones only when we want to allow updating with the built-in updater? There should be no issue with possible downgrades of 4.5 users to 4.0.8 in this case as the updater related code is comparing versions and does not install the update if the proposed update has a lower version number IIRC.

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

Replying to gk:

That would be one option, yes. Applied to master in commit 7d7faa30b4443f0cc76474738a36fd3f45e875f4. Do we really think this were necessary if we would just avoid updating the update responses files in the first place and deliver the updated ones only when we want to allow updating with the built-in updater? There should be no issue with possible downgrades of 4.5 users to 4.0.8 in this case as the updater related code is comparing versions and does not install the update if the proposed update has a lower version number IIRC.

I forgot to respond to this... yes, there should not be any downgrade issues.

Replying to mcs:

Replying to gk:

That would be one option, yes. Applied to master in commit 7d7faa30b4443f0cc76474738a36fd3f45e875f4. Do we really think this were necessary if we would just avoid updating the update responses files in the first place and deliver the updated ones only when we want to allow updating with the built-in updater? There should be no issue with possible downgrades of 4.5 users to 4.0.8 in this case as the updater related code is comparing versions and does not install the update if the proposed update has a lower version number IIRC.

I forgot to respond to this... yes, there should not be any downgrade issues.

boklm: So what is the exact scenario then which makes the patch necessary? I seem to be missing something. If we can get away with the idea mentioned in comment:4 I think backing this patch out might be the cleanest approach saving us some work (we'd need to upload update response files just once instead of twice).

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

Trac:
Status: reopened to needs_information

Yes, if the updater code checks that the proposed upgrade is not a downgrade, then we can just avoid updating the update response files, instead of using the "no_update_for" option added by this patch. So the patch is not necessary.

Ok. I've reverted it in commit 6fddec33ed9d3baf343f3848bc3d85553de6b03b for now to make the releasing not more complex as it already is.

Trac:
Status: needs_information to closed
Resolution: N/A to wontfix

closed

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