Open Stack

On Nov 13, 2014, at 3:52 AM, Thierry Carrez <thierry at 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 arise.

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).

Doug