Opened 8 years ago

Closed 8 years ago

#3827 closed defect (fixed)

torbrowser lacks changelog

Reported by: phobos Owned by: mikeperry
Priority: High Milestone: TorBrowserBundle 2.2.x-stable
Component: Firefox Patch Issues Version:
Severity: Keywords:
Cc: erinn, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


We've been using as a changelog for years. It's time to move all of this to a dedicated Changelog file, and put in every change between versions.

For example, the README states:

1.3.27: Released 2011-08-19

Update Firefox to 3.6.20
Update Libevent to 2.0.13-stable
Update HTTPS-Everywhere to 1.0.0development.5

but the blog states:
Tor Browser Bundle (2.2.31-1) alpha; suite=all

Update Tor to
Update Firefox to 6.0
Update Libevent to 2.0.13-stable
Update NoScript to
Update HTTPS Everywhere to 1.0.0development.5
Remove BetterPrivacy until we can figure out how to make it safe in all bundles (see #3597)

Is that really all of the changes to TBB? No configuration changes, no changes to prefs.js between versions?

Child Tickets

Change History (6)

comment:1 Changed 8 years ago by mikeperry

Cc: erinn added

The prefs.js changes (which I agree should be documented) are Erinn's domain.

Right now, there are only three patches that I have done to Tor Browser itself. But yes, those should be documented, too.

How should we unify the changelogs of the addons in the bundle, prefs.js, torbutton, and Tor Browser? Should we just produce one document?

comment:2 Changed 8 years ago by arma

Yes, I think one document is best. The TBB packages come with version numbers, and there should be a single place to go to find out what components are intended to be in that TBB version, and what configuration changes (of all sorts) happened between one version and the next.

comment:3 Changed 8 years ago by arma

Cc: arma added

I'm excited to see this one happen. :)

comment:4 in reply to:  3 Changed 8 years ago by mikeperry

Milestone: TorBrowserBundle 2.2.x-stable
Priority: normalmajor

Replying to arma:

I'm excited to see this one happen. :)

Let's update some ticket properties in that case.

Also, what should we do about past releases? How far should we go back?

comment:5 Changed 8 years ago by erinn

Well, who are the changelogs for? I think the answer to that helps decide the format. Changelogs for developers are way different from changelogs for users. I'd been using the git repo as a 'dev changelog', and leaving only obvious high-level changes in the README/changelog in the bundle itself.

I'm happy to add more detail though. But in the case of prefs.js changes, which are actually mikeperry-driven (usually), and other such things, I think we should adopt a tor-repo-esque situation where if someone contributes a change, they also contribute a well-summarized changes file.

As for the patches, those are documented within the patches themselves, and that is the appropriate place according to the HACKING doc in torbrowser.git/maint-2.2. And with past releases, I think we should begin relatively "new" with maint-2.2, go through and look through git commits & the changelog itself, and flesh out the missing pieces in a doc that is not HACKING, but something more appropriately named (not changelog.omnibus either, but... well, maybe!)

comment:6 Changed 8 years ago by mikeperry

Resolution: fixed
Status: newclosed

I believe our last two changelogs are properly documenting patches, config changes, and torbutton changes.

Please reopen if anyone disagrees.

Note: See TracTickets for help on using tickets.