On 18 March 2015 at 03:03, Doug Hellmann <d...@doughellmann.com> wrote: > Now that we have good processes in place for the other Oslo libraries, I > want to bring pbr into the fold so to speak and start putting it through > the same reviews and release procedures. We also have some open bugs > that I'd like to find someone to help fix, but because we can't actually > release from the master branch right now working on fixes is more > complicated than it needs to be. I don't want to focus on placing blame, > just understanding where things actually stand and then talking about > how to get them to a better state.
+1. > From what I can tell, the main problem we have in master right now > is that the new semver rules added as part of [1] don't like some > of the existing stable branch tags being used by projects. This > feels a bit like we overreached with the spec, and so I would like > to explore options for pulling back and changing directions. It is > quite likely I don't fully understand either the original intent > or the current state of things, but I want to start the discussion > with the hope that those with the details can correct my mistakes > and fill in any gaps. My understanding is different. The thing preventing a release of trunk was that pbr and PEP-440 ended up (after lots of effort!) at odds, and pip strictly implements PEP-440. The key change is to tweak the generation of versions when pre-release tags are in play. Given this state: commit X commit Y tagged 1.2.3.alpha1 commiy Z tagged 1.2.2 PEP-440 says that 1.2.3.alpha1.dev1 is legitimate but we'd chosen to do 1.2.3.dev2 - discarding the .alpha1 and walking back to the last tag. I don't recall the exact detail of the conflict here - but its all in -infra channel logs if that matters. Making the change should be pretty straight forward. A second but also mandatory change is to synchronise on the final pre-release tag definitions in PEP-440, IIRC that was just 'rc' -> 'c'. With those done we should be able to release trunk. *all* the extra bits are extra and should not hold up releases .... On 'do what I say' for version numbers, pbr still permits that: if you tag, it will honour the tag. I'd like eventually to make it error rather than warn on weirdness there - both the requirement that things be in canonical form, and the insistence on honouring semver (no API breaking .minor releases!) - are aids for interop with pip and PEP-440. To reiterate the current situation (AIUI) is warn not enforce, and no action should be needed here. > Some of the other special casing seems to be for TripleO's benefit > (especially the stuff that generates versions from untagged commits). > Is that working? If not, is it still necessary to have? Huh, no. Thats all about unbreaking our behaviour in the gate. We've had (and can still have with current released) cases where we end up installing from pypi rather than the thing we're testing, if the version numbers align wrongly. (All due to accidentially rewinding versions in the presence of pre-release versions). Pbr has generate versions forever. It just generates completely broken ones in the released code. Yes broken - they go backwards :). > The tag-release command isn't necessary for OpenStack as far as I > can tell. We have a whole separate repository of tools with > release-related scripts and tooling [2], and those tools automate > far more than just creating a tag for us. I don't expect any OpenStack > project to directly use a pbr command for creating a tag. Maybe we > missed the window of opportunity there? How much of that work is done? > Should we drop any remaining plans? I think we can defer this part of the conversation. > Did I miss anything that's currently broken, or needs to be done before > we can consider pbr releasable for liberty? We should update the spec as we do this. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
