Open Stack

On 4 August 2015 at 06:06, Doug Hellmann <doug at doughellmann.com> 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud