Re: [openstack-dev] [oslo] alpha version numbering discussion from summit
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 ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] alpha version numbering discussion from summit
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 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] alpha version numbering discussion from summit
On 2014-11-13 07:50:51 -0500 (-0500), Doug Hellmann wrote: [...] 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. [...] Many of us have suggested this as a possible way out of the tangle in the past, though Monty was the one who raised it during that session. Basically the problem we have boils down to wanting to use these libraries as a stable internal communication mechanism within components of an OpenStack environment but also be able to support tenant users and application developers interacting with a broad variety of OpenStack releases through them, and that is a mostly unreconcilable difference. Having a user-facing SDK which talks to OpenStack APIs with broad version support, and a separate set of per-project communication libraries which can follow the integrated release cadence and maintain stable backport branches as needed, makes the problem much more tractable in the long term. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] alpha version numbering discussion from summit
On Nov 13, 2014, at 12:41 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-11-13 07:50:51 -0500 (-0500), Doug Hellmann wrote: [...] 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. [...] Many of us have suggested this as a possible way out of the tangle in the past, though Monty was the one who raised it during that session. Basically the problem we have boils down to wanting to use these libraries as a stable internal communication mechanism within components of an OpenStack environment but also be able to support tenant users and application developers interacting with a broad variety of OpenStack releases through them, and that is a mostly unreconcilable difference. Having a user-facing SDK which talks to OpenStack APIs with broad version support, and a separate set of per-project communication libraries which can follow the integrated release cadence and maintain stable backport branches as needed, makes the problem much more tractable in the long term. That makes sense. If we go that route, there is a good chance we will want to reconsider the decision to deprecate the apiclient and cliutils modules in the incubator, since there would still be good value in maintaining those as shared code for the internal client libraries. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
