348135 - How about a software rollback system?

Status: RESOLVED DUPLICATE of bug 310302

(Toolkit :: Application Update, enhancement)

Description

[Declan Naughton]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b1) Gecko/20060809 BonEcho/2.0b1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b1) Gecko/20060809 BonEcho/2.0b1

It seems really easy to implement (backup the files before you replace them), although I don't know much about the details.

As for the UI, in the Update History dialog the entries could be clickable and then a rollback button is enabled. Maybe the update history dialog could be accessible in Help > About too, somewhere close to the agent string?

It should also be accessible using a command-line option, in case an update means Firefox won't start in some situations.

tbh no, I can't think of many use-cases, but it doesn't seem very hard to implement (if it actually is, then that's a different story), and it might save some people a lot of bother.

Reproducible: Always

Comment 1

[Declan Naughton]

Would this be easy to do? Since the .mar files contain files that'll replace the previous files, if you just rename the previous file and append the old version string to it (as opposed to overwriting it), I think then it shouldn't be very difficult to make it work.

I'm kinda just throwing the idea out there, I can't be sure that it won't be hard, but other people reading this /can/, and they can feel free to educate me.

As for use-cases, if an update happens to break something - anything, an extension or anything else, it would be useful to be able to simply rollback to an earlier version. And the new features that are brought in with every major release, some people just don't need/want them, so if somehow they (auto-)update to them, it would be useful for them to be able to easily rollback.

They're not the most important use-cases, but they're there and there may be more. So /if it's not too much work/ it mightn't be a bad idea to do this.

Comment 2

[Darin Fisher]

Are roll-backs sticky?  How does one revert to being on the regular update-train?

While it is true that you can apply any complete MAR file to any installation of Firefox and jump to that version of Firefox, it probably wouldn't be very simple to build the server-side support for this feature.

I think this bug is probably WONTFIX, and the correct answer is "let's not screw over extensions when we push automatic updates" and folks who really want to roll-back to an older release can download that release manually and disable auto-update.

Comment 3

[Declan Naughton]

(In reply to comment #2)
> Are roll-backs sticky?  How does one revert to being on the regular
> update-train?

I suppose, when they rollback you could ask them something like, "Would you like to disable auto-updates for Firefox? You can re-enable auto-updates in Preferences > Advanced > Update".

> While it is true that you can apply any complete MAR file to any installation
> of Firefox and jump to that version of Firefox, it probably wouldn't be very
> simple to build the server-side support for this feature.

My proposal would not require the MAR files to stay. When a MAR file is installed, files it replaces are renamed with the version string of the previous Firefox version appended to it. So when updating from Firefox 1.5.0.1 to 1.5.0.2 and say classic.jar (note that I've no idea which files are generally replaced during an update) is replaced, the original classic.jar will be renamed to classic.jar-1.5.0.1 and then the classic.jar in the new MAR file will just be copied into place.

When rolling back from 1.5.0.2 to 1.5.0.1, the (new) classic.jar will either be removed or renamed (you could rename it to classic.jar-1.5.0.2 to enable rolling forward without the need for keeping the MAR file) and classic.jar-1.5.0.1 will be renamed to classic.jar.

Comment 4

[Declan Naughton]

Haven taken a look at the code for the updater program, backing up the modified files before updating them shouldn't involve too much work thanks to the backup_* functions that are already used (remove the call to backup_discard in backup_finish, and then make references to BACKUP_EXT references to a new char * variable that's set to the version of the program). Then extend the updater program to actually do the rollbacks, then get the UI work done :)

I'm gonna look into doing this myself. I ain't no pro-programmer, but this would be a great learning experience even if it doesn't get committed.

Comment 5

[Declan Naughton]

Another use-case: for regression testing, it would be easy for testers to rollback and forward through nightlies to find when the regression came in.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Is this a dupe of 310302?

Comment 7

[Declan Naughton]

*** This bug has been marked as a duplicate of 310302 ***