Re: [openstack-dev] [release] Release model for feature-complete OpenStack libraries
writes: > How will we handle which versions of libraries work together? > And which combinations will be run thru CI? Dependency management will work the same way it does today. Each component (server or library) lists the versions of the dependencies it is compatible with. That information goes into the packages built for the component, and is used to ensure that a compatible version of each dependency is installed when the package is installed. We control what is actually tested by using the upper constraints list managed in the requirements repository. There's more detail about how that list is managed in the project team guide at https://docs.openstack.org/project-team-guide/dependency-management.html Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release] Release model for feature-complete OpenStack libraries
How will we handle which versions of libraries work together? And which combinations will be run thru CI? -Original Message- From: Thierry Carrez Sent: Friday, September 28, 2018 7:17 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [release] Release model for feature-complete OpenStack libraries [EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information. Hi everyone, In OpenStack, libraries have to be released with a cycle-with-intermediary model, so that (1) they can be released early and often, (2) services consuming those libraries can take advantage of their new features, and (3) we detect integration bugs early rather than late. This works well while libraries see lots of changes, however it is a bit heavy-handed for feature-complete, stable libraries: it forces those to release multiple times per year even if they have not seen any change. For those, we discussed[1] a number of mechanisms in the past, but at the last PTG we came up with the conclusion that those were a bit complex and not really addressing the issue. Here is a simpler proposal. Once libraries are deemed feature-complete and stable, they should switch them to an "independent" release model (like all our third-party libraries). Those would see releases purely as needed for the occasional corner case bugfix. They won't be released early and often, there is no new feature to take advantage of, and new integration bugs should be very rare. This transition should be definitive in most cases. In rare cases where a library were to need large feature development work again, we'd have two options: develop the new feature in a new library depending on the stable one, or grant an exception and switch it back to cycle-with-intermediary. If one of your libraries should already be considered feature-complete and stable, please contact the release team to transition them to the new release model. Thanks for reading! [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131341.html -- The Release Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [release] Release model for feature-complete OpenStack libraries
Hi everyone, In OpenStack, libraries have to be released with a cycle-with-intermediary model, so that (1) they can be released early and often, (2) services consuming those libraries can take advantage of their new features, and (3) we detect integration bugs early rather than late. This works well while libraries see lots of changes, however it is a bit heavy-handed for feature-complete, stable libraries: it forces those to release multiple times per year even if they have not seen any change. For those, we discussed[1] a number of mechanisms in the past, but at the last PTG we came up with the conclusion that those were a bit complex and not really addressing the issue. Here is a simpler proposal. Once libraries are deemed feature-complete and stable, they should switch them to an "independent" release model (like all our third-party libraries). Those would see releases purely as needed for the occasional corner case bugfix. They won't be released early and often, there is no new feature to take advantage of, and new integration bugs should be very rare. This transition should be definitive in most cases. In rare cases where a library were to need large feature development work again, we'd have two options: develop the new feature in a new library depending on the stable one, or grant an exception and switch it back to cycle-with-intermediary. If one of your libraries should already be considered feature-complete and stable, please contact the release team to transition them to the new release model. Thanks for reading! [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131341.html -- The Release Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
