Or you could use pbr's strategy, which tags based on git tags and
revision history:
https://docs.openstack.org/developer/pbr/#version
"If the currently checked out revision is not tagged, then we take the
last tagged version number and increment it to get a minimum target
version."
Best,
-jay
On 04/13/2017 04:14 AM, Bogdan Dobrelya wrote:
On 13.04.2017 0:59, Michał Jastrzębski wrote:
My dear Kollegues,
Today we had discussion about how to properly name/tag images being
pushed to dockerhub. That moved towards general discussion on revision
mgmt.
Problem we're trying to solve is this:
If you build/push images today, your tag is 4.0
if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
we tag new release.
+1 that this should be improved, indeed.
But image built today is not equal to image built tomorrow, so we
would like something like 4.0.0-1, 4.0.0-2.
Please take a look the build flow for a neighbour project Kubernetes
[0]. I believe it addresses each of the possible versioning aspects,
like stable branch builds, master builds, infrastructure vs local builds
and so on. Kolla could reuse some build scripts and follow the similar
versioning scheme from that project and save time as well.
[0] https://github.com/kubernetes/kubernetes/tree/master/build#basic-flow
While we can reasonably detect history of revisions in dockerhub,
local env will be extremely hard to do.
I'd like to ask you for opinions on desired behavior and how we want
to deal with revision management in general.
Cheers,
Michal
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
