Excerpts from Robert Collins's message of 2015-03-19 09:15:36 +1300: > 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 wonder if it had to do with Oslo's alpha releases? Since we're no longer doing that, do we still care? Are we still actually "broken"? > > 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'. How do we use those? > > 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. OK, so the problem was with installing packages with "bad" versions, rather than building them in the first place? I thought maybe someone closer to the issue would remember the details. I should probably just try to use trunk pbr and see where it's failing, if at all. > > > 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 :). By pre-release do you mean things with "alpha" in them, or do you mean commits that were made after a release tag? > > > 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. Yes, it would be really good to have a concrete list of things we need to bring master back into a working state. It sounds like we're closer than I expected, which is good. Doug > > -Rob > __________________________________________________________________________ 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