This package is maintained in a Git repository on Alioth.

It uses the Debian 3.0 (quilt) source format, with multiple upstream tarballs.
As such, it cannot follow the typical workflow with git-buildpackage as
git-buildpackage doesn't support (yet?) multiple tarballs.

The upstream version has the following form: x.y.0c1e2m3s4-z
x.y corresponds to the major/minor version of rspec.
first number after x.y (0 in the example):
  the number of the revision for rspec gem 
number after c: revision for rspec-core
number after e: revision for rspec-expectations
number after m: revision for rspec-mocks
number after s: revision for rspec-support


The workflow for the moment is the following:


detect a new upstream version
-----------------------------

No automatic centralized debian/watch (yet).
use ./debian/rules report


update to a new upstream version
--------------------------------

use the following targets from debian/rules:

- debian/rules get-orig-sources: 
    download and create the multiple upstream tarballs
- debian/rules unpack-sources:
    unpack the sources, to be committed in the upstream branch
    (awkward, because debian/rules is not present in the upstream branch...)
- debian/rules gen-gemspecs:
    interpret upstream 'source' gemspec to real ones, with shell commands
    (calls to git), and store them in the debian/ directory
    to be committed to the master branch
    update then debian/patches/gemspecs.patch with the diff between upstream
    source gemspecs and the generated ones.

dpkg-source automatically creates an empty upstream main tarball for the source
package, and will use the several components tarball.

The tarballs are stored in the pristine-tar branch.

 -- Cédric Boutillier <boutil@debian.org> 2015-04-01
