I guess what I am driving at is that the process of creating a tag
in
the OpenStack client projects occurs at pretty arbitrary points in
time based on the needs of other OpenStack projects that want to set
requirements on them rather than anything relating to the needs of
downstream distributions such as RDO or RHELOSP. Because no other
OpenStack project needed the particular functionality (and fixes)
added to python-novaclient in the last three months no new tag was
requested nor created. In this case it means we're missing some 84
odd commits made since the 2.17.0 tag was created.
Yup, exactly. We've had features that were cross-project that had client
changes required. We'd push the change into nova, then push into
novaclient, tag the novaclient, update requirements for the other
project, push that change, etc.
On the other hand, we also have "huh, we haven't done a client release
in a while" moments. For examples like nova events, instance groups,
etc, I think it makes plenty of sense to stay current on the client
packages.
Given this what I'm wondering is if there is any reason we
shouldn't
move to a model where we rebase the python-*client packages to the
latest git commit at each milestone (J-1, J-2, J-3, RC, GA),
regardless of the existence of a tag, to ensure we are always picking
up the latest changes?
Assuming proper testing of course, +1 from me.
--Dan