On Nov 13, 2014, at 3:52 AM, Thierry Carrez <thie...@openstack.org> wrote:

> Doug Hellmann wrote:
>> The outcome of the “Should Oslo continue to use alpha versions” session at 
>> the summit [1] was unclear, so I would like to continue the discussion here.
>> As we discussed at the summit, the primary reason for marking Oslo library 
>> releases as alphas was to indicate that the library is under development and 
>> not “stable”, so it should not be included in a deployment using stable 
>> branches. 
>> I think we were very close to being able to say that Oslo could stop using 
>> Alpha versions for new library releases because we would pin the versions of 
>> libraries used in the stable branches to MAJOR.MINOR+1 to only allow bug-fix 
>> releases to appear in deployments using those branches. However, we will not 
>> (and perhaps cannot) pin the versions of client libraries, and some of the 
>> clients are now using oslo.utils and potentially other oslo libraries. This 
>> would either break the clients (if they used a feature of an oslo library 
>> not in the version of the library supported by the server) or the server (if 
>> the oslo library is upgraded and a setuptools requirements check notices or 
>> some feature has been removed from the oslo library).
>> We came to this realization just as we were running out of time for the 
>> session, so we did not come up with a solution. I wasn’t able to attend the 
>> stable branch session, so I am hoping that someone who was there will be 
>> able to explain a bit about the version pinning discussion and how that may, 
>> or may not, affect Oslo library versioning.
> The stable branch discussion happened before the Alpha versioning one.
> In that discussion, we considered generally pinning dependencies for
> stable branches, to reduce breakage there and make it more likely we
> reach 15months+ of support.
> That said, since we don't have stable branches for client libraries, we
> didn't plan to pin those, so we might still need to bump the client
> libraries dependencies in stable/* requirements as they evolve.
> Technically, we wouldn't really be freezing the stable requirements, we
> would just bump them on a "as needed" basis rather than automatically.
> As far as the alpha versioning discussion goes, I think it could work,
> as long as a released client library won't depend on an alpha of an oslo
> library (which I think is a reasonable assumption). We would just need
> to somehow remember to bump the oslo library in stable/* requirements
> when the new client library depending on a new version of it is
> released. Not sure how we can do that before the client library bump
> breaks the branch, though ?

That’s basically what we’re doing now. If we allow Oslo lib versions with new 
features to make it into the stable branches, we introduce some risk of 
backwards-incompatible changes slipping into the libraries. It’s unlikely we’d 
have an API change like that, since they are easy to spot, but we may have 
untested behaviors that someone depends on (the recent case of syslog 
addressing moving from /dev/log to the UDP port is a good example of that). I’m 
personally OK with that risk, as long as its understood that there’s not a huge 
team of people ready to drop whatever they’re doing and fix issues when they 

I do remember a comment at some point, and I’m not sure it was in this session, 
about using the per-project client libraries as “internal only” libraries when 
the new SDK matures enough that we can declare that the official external 
client library. That might solve the problem, since we could pin the version of 
the client libraries used, but it seems like a solution for the future rather 
than for this cycle.

Another solution is to require the client libraries to include support for 
multiple versions of any libraries they use (Oslo or third-party), which allows 
us to pin those libraries in stable branches and still have more recent 
versions available in clients that aren’t running in the stable environments. 
That may mean the clients don’t include some features when running in older 
environments, but as long as no bug fixes are involved I don’t see that as a 
major technical issue (leaving aside the hassle of having to write 
version-aware code like that).


OpenStack-dev mailing list

Reply via email to