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.
>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. It looks like [1] had several goals. It was meant to fix the automatically generated version numbers for untagged revisions, bring us up to standard with current pip rules for version numbers, improve our support for distro version number generation, and enforce semver automatically by looking at comments on commits when creating a new tag. Is it the last part that's "broken"? Can we make pbr just "do what I say" with version numbers, and build a standalone tool (maybe installed as part of pbr) for suggesting tags using whatever rules we like? That would be like the proposed next-version command, but not invoked through setup.py. I don't actually care what the UI is, but I do think we want any rules about what versions are "allowed" ignored when the *existing* tags are parsed, so moving them out of the setuptools commands entirely seems like an easy way to ensure that. 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? 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? Did I miss anything that's currently broken, or needs to be done before we can consider pbr releasable for liberty? Doug [1] http://specs.openstack.org/openstack/oslo-specs/specs/juno/pbr-semver.html [2] http://git.openstack.org/cgit/openstack-infra/release-tools/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
