On 4 August 2015 at 06:06, Doug Hellmann <[email protected]> wrote: > Excerpts from Thierry Carrez's message of 2015-08-03 18:11:53 +0200: >> Jeremy Stanley wrote: >> > On 2015-08-03 14:46:51 +0200 (+0200), Thierry Carrez wrote: >> > [...] >> >> In order to make this work, it looks like we'd require: >> >> >> >> * pbr changes so that it supports a mode where every commit on the >> >> branch increments .Z >> >> >> >> * infra changes to automatically push the corresponding tag when the >> >> commit is merged >> > [...] >> > >> > Note that these were alternatives: _either_ we need PBR to treat >> > commits as patch version increments (instead of as dev version >> > increments), _or_ we'd need a mechanism to automatically tag each >> > commit so that PBR will see the appropriate versions. >> >> I could see an implementation where we do both, though: PBR could >> idempotently yield the right version number, but we would still tag it >> in the repo for easier reference when looking at the git repository ? >> > > We could do that. I had been thinking of just baking this into pbr, > but now that you point out the need for referring to version tags > from outside the repo, I wonder if Ian isn't right that a job to > just generate the tags would be simpler to manage. If we build it > to submit a proposal to the releases repo at the same time, we would > get the history tracking, too.
I think tagging is basically the only sensible route. Untagged commits require some oracle to determine 'is this the stable branch *itself* or not. [Because local developer branches should not generate versions that could be uploaded to PyPI]. -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
