On Tue, Jun 17, 2014 at 6:42 PM, Robert Collins <robe...@robertcollins.net> wrote: > On 11 June 2014 04:24, Doug Hellmann <doug.hellm...@dreamhost.com> wrote: > ... >> Incubated libraries have been released at the end of a release cycle, >> as with the rest of the integrated packages. Adopted libraries have >> historically been released "as needed" during their development. We >> would like to synchronize these so that all oslo libraries are >> officially released with the rest of the software created by OpenStack >> developers. > > So I see a fairly big problem with this - its going to impact heavily > on anyone that isn't part of oslo using oslo.* as a library. For > instance, the openstack clients which use oslo.config - they will not > be able to get new features or bugfixes from trunk without waiting 6 > months. And that means either: > - carrying conditional code (version checking the version of oslo) in > their trunk, > - or not consuming new features until up to 6 months after release > - or making their trunk *uninstallable* (because it will have either > an dep on a non-existing version, or a dep on an old version that > doesn't actually include the needed feature). > > The last option is what I suspect will happen, and that will be very > sad, since it seems unneeded. It will also make version management > hard for CD deployers (like TripleO's deploy-trunk default) because > incorrect requirements files are anaethema.
I don't follow that. What does synchronizing the release cycles have to do with whether or not things are installable? In order to make use of the library in unit tests, the project will have to have the correct versions in their requirements file so the package can be installed from pypi -- including allowing an alpha release if that's where the feature is. To allow unit tests to work on developer systems, we will tag alpha releases and publish them to pypi. AFAICT, the only thing that's special about those releases is that they will be wheels instead of sdists. > Markmc's mail about wanting the same rhythm doesn't make sense to me > since more than half the openstack artifacts *do not have* the 6 month > rhythm - client libraries have always been semver, release when ready. > > AIUI the stable branches thing in the server space exists to give us > freedom to evolve the code super rapidly, in these large, fairly > monolithic APIs; we need it because we are always > backward-incompatible between server /releases/ (only of the server > HTTP API) - if we do semver, we'd be doing a breaking release every 6 > months. So stable branches is a valve to balance trunk velocity of > independent codebases vs user demands for bugfixes and security fixes. > > The other basic model we have as software releasers is to do stable > branches only when a backwards incompatible change has happened - > thats what we demand from projects like setuptools *and our client > libraries*: we want to be able to fork at that point, but the default > behaviour is not to fork, and instead just not break things. And that's what I plan to do with Oslo. I mentioned stable branches as a solution for security fixes mainly, though I wouldn't say "only". I don't expect to be doing a lot of back-porting of insignificant fixes, since we hardly have enough reviewers to cover the changes we're trying to make now. > > "Not break things" is roughly proportional to the size of the > codebase, and the oslo projects are typically small focused projects > where this seems reasonable to expect. *More than that*, I believe its > essential, or we'll have a very hard time propogating new releases out > amongst the servers. Believe me, I know how hard it can be to update the version of a library used by more than one project in OpenStack. That's why I have been focusing so much attention on figuring out how to handle the cross-testing at the unit test level, so we know in the gate when a change in a library is going to break one of the servers, and can reject the patch. > > tl;dr there seems to be no reason to do one release every 6 months of > olso.*, and doing so seems likely to only incur costs, since the > discipline needed to do regular semver with good backwards compat is a > discipline we're going to have to exercise anyway. As you point out, most of these libraries are small. I don't actually expect to create new releases of all of them every cycle. In fact, I expect most of them to be extremely stable over time. Doug > > -Rob > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
