On 30 July 2015 at 01:39, Sean Dague <[email protected]> wrote: > So, after every release a giant amount of patches all have to land lock > step or everything is broken?
No, its not that bad. The *tagged* commit is fine forever. The *first* commit in each branch has to be the identification of the new version in that branch. So there is no race, and as long as you put up the new patch straight away (which is AIUI part of the release manager process), everyone else can Depends-On: I.... that patch, and things will be sane. That said, yes, removing the version= line as unnecessary should make things a lot simpler. The change in pbr 0.11 was to fix a bug: the bug was that when there is a version in setup.cfg, and a tag thats equal or higher, there are no versions to pick from by the backwardly defined rules for setup.cfg: the old code happily generated versions *IN THE PAST*. The new code had a choice: - error - decide it knew better than the owner of setup.cfg and start incrementing versions above it At the time we chose to error, based on the reasoning that: - there was already a process to put new versions in setup.cfg at release time - the gate wouldn't be broken at all because its self checking - overriding pre-versioning seemed against the entire *intent* of pre-versioning. If a bunch of folk are going to say 'hey, we want a knob to make this take the 'decide pbr knows better' path, I'm entirely willing to support just changing the decision from 'error' to 'decide it knows better'. It was arbitrary but conservative. However - see above - I think the impact of the release is being overstated. If I have that wrong, please help me understand whats happened here. -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
