[tor-bugs] #9425 [BridgeDB]: Create and document a better BridgeDB (re)deployment strategy

[Tor Bug Tracker & Wiki]

#9425: Create and document a better BridgeDB (re)deployment strategy
------------------------+---------------------------------------------------
 Reporter:  isis        |          Owner:  isis          
     Type:  task        |         Status:  needs_revision
 Priority:  normal      |      Milestone:                
Component:  BridgeDB    |        Version:                
 Keywords:  deploy,doc  |         Parent:                
   Points:              |   Actualpoints:                
------------------------+---------------------------------------------------
Changes (by isis):

  * status:  new => needs_revision


Comment:

 Yesterday I implemented item no. 1, listed above.

 Now, for example, we have the following:
 {{{
 (bridgedb)∃!isisⒶwintermute:(testing/sysrqb/bug9157_r2_rebase-cherrypick-
 a31c592e>)~/code/torproject/bridgedb ∴ make test
 python setup.py test
 running test
 running build
 got version from git {'version': '0.0.1-4-gb540f43', 'full':
 'b540f436592fe9cb150ad56eb820045b4a97ced8'}
 running build_py
 }}}

 Meaning that the most recent tag was `0.0.1`, this is the fourth unique
 build since that tag, and the short ID of the git commit the build was
 made from is `gb540f43`. So next time a deployment is made, no matter who
 it's made by, they should be able to determine where which branch was
 checked out and how many changes were made before it went live.

 The commit message which implemented this explains how to bump version
 numbers, but I'll stick it here to, just for the record:
 {{{
 * | commit 7227e6e47c7161d7639a27fd206be64aafae8549
 | | gpg: Signature made Mon 19 Aug 2013 23:52:35 UTC
 gpg:                using RSA key A3ADB67A2CDB8B35
 gpg: Good signature from "Isis! <isis at patternsinthevoid.net>" [ultimate]
 gpg:                 aka "Isis <isis at leap.se>" [ultimate]
 gpg:                 aka "Isis! <isis at riseup.net>" [ultimate]
 gpg:                 aka "Isis <isis at torproject.org>" [ultimate]
 gpg: Signature notation:
 isis at patternsinthevoid.net=0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
 gpg: Signature expires Tue 19 Aug 2014 23:52:35 UTC
 Author:     Isis Lovecruft <isis at torproject.org>
 | | AuthorDate: 19 hours ago
 | | Commit:     Isis Lovecruft <isis at torproject.org>
 | | CommitDate: 18 hours ago
 | |
 | |     Start using automatic versioning system.
 | |
 | |      * FIXES part of #9425 (Create and document a better BridgeDB
 deployment
 | |        strategy).
 | |      * ADD versioneer.py to the top level of the project.
 | |      * USE setuptools explicitly in setup.py, which will also make the
 project a
 | |        bit more py3k compatible.
 | |      * ADD maintainer and maintainer_email fields to setup.py setup()
 call (with
 | |        my contact info).
 | |      * ADD versioneer setup variables and calls to setup.py.
 | |
 | |     Versioneer, as currently configured, will automatically create a
 package level
 | |     attribute:
 | |
 | |      >>> import bridgedb
 | |      >>> print bridgedb.__version__
 | |      0.0.1
 | |
 | |     Bumping the version number at release time (which, for BridgeDB
 really means
 | |     deploy time, as of right now) means doing the following:
 | |
 | |      $ git checkout develop
 | |      [merge some fix/bug/feature/etc branches]
 | |      $ git checkout -b release-0.0.2 develop
 | |      $ git tag -a -s bridgedb-0.0.2
 | |      [pip maintainance commands *would* go here, if we ever have any]
 | |      $ git checkout master
 | |      $ git merge -S --no-ff release-0.0.2
 | |      $ git checkout develop
 | |      $ git merge -S --no-ff master
 | |      $ git push <remote> master develop
 | |
 | |     And be sure not to forget to do:
 | |
 | |      $ git push --tags
 | |
 | |     If the currently installed version is *not* from one of the signed
 tags, the
 | |     version number attribute created by versioneer will be the short
 ID of the git
 | |     commit from which the installation took place, prefixed with the
 most recent
 | |     tagged release at that point, i.e.:
 | |
 | |      >>> import bridgedb
 | |      >>> bridgedb.__version__
 | |      0.0.1-git528ff30c
 | |
 | |  .gitattributes           |   1 +
 | |  lib/bridgedb/__init__.py |   4 +
 | |  lib/bridgedb/_version.py | 197 +++++++++++++++++++
 | |  setup.py                 |  73 ++++---
 | |  versioneer.py            | 656
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 | |  5 files changed, 906 insertions(+), 25 deletions(-)
 }}}

 I made a tag, `'bridgedb-0.0.1'` just to initialize the automatic
 versioning system.

 '''I propose the following bumping strategy''': Because aagbsn (or maybe
 someone else beforehand) was calling the current version `'0.1.0'` I'm
 going to tag `'bridgedb-0.1.1'` as the first release thus far with the
 versioning system, and each deployment afterwards will get the micro
 version number bumped, so the next one will be `'bridgedb-0.1.2'`. The
 minor version number should get bumped whenever "significant" changes are
 made (for some as-yet-to-be-defined and arbitrary def__n__s of
 "significant"), and the major version number should get bumped when
 behaviour is so altered that it is incompatible with the previous version.
 I also propose keeping a `CHANGELOG` file.

 I'm '''not actually set on this version-number-bumping strategy''', so
 ideas are welcome.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9425#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online