Excerpts from Alan Pevec's message of 2015-08-05 16:14:32 +0200: > >> > > > 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.
We intend to have that release process automated further, so why don't we build this auto-tagging system to submit a patch to the releases repository instead of doing the tag directly. That way we have the full history for the release documentation we're planning to generate. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
