>> > > > To give you an idea, if we enabled that for Kilo we'd be at Nova >> > > > 11.0.80 >> > > > (kilo) and Nova 10.0.218 (juno). >> > > I am not a fan of doing this second option at all. We would be polluting >> > > the ref space of our repos with redundant information making the output >> > > of `git tag` unusable to humans. If this was not redundant info and a >> > > tag of 11.0.80 provided more information than a generated version of >> > > 11.0.0.dev80 / 11.0.80 I think we could live with that, but it does not.
It actual does: auto-tagged commit means it passed our CI hence project "stands behind it". PBR-generated Z-version could be just local change which has never seen any CI yet. > Using pbr to generate versions avoids that problem, but introduces the > challenge of not being able to necessarily figure out which commit > corresponds to a given version number from the outside. Say I want to > check out version 11.0.80 for some reason (maybe .81 has a bug I don't > want to deploy). How do I do that without a tag? That also, PBR-generated version is not universally reproducible. So what about making auto-tagging on stable branches optional for projects: by default if project has a stable branch(es) they will get auto-tagging but project could also opt-out and push X.Y.Z tags themselves, via the same release process like Oslo and clients. Cheers, Alan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
