Re: [openstack-dev] [all] [release] How to handle "stable" deliverables releases
On 06/11/2018 11:53 AM, Thierry Carrez wrote: > Hi everyone, > > As some of the OpenStack deliverables get more mature, we need to adjust > our release policies to best handle the case of deliverables that do not > need to be updated that much. This discussion started with how to handle > those "stable" libraries, but is actually also relevant for "stable" > services. > > Our current models include cycle-tied models (with-intermediary, > with-milestones, trailing) and a purely cycle-independent model. Main > OpenStack deliverables (the service components that you can deploy to > build an OpenStack cloud) are all "released" on a cycle. Libraries are > typically maintained per-cycle as well. What happens if no change is > pushed to a service or library during a full cycle ? What should we do > then ? > > Options include: > > 1/ Force artificial releases, even if there are no changes > 2/ Do not force releases, but still create branches from latest releases > 2bis/ Like 2, but only create the branch when needed > 3/ Do not force releases, and reuse stable branches from cycle to cycle > 4/ Stop worrying about stable branches at all for those "stable" things FYI, for downstream distribution maintainers, any evolution from 1/ is fine: it's a bit silly for us to just rebuild a new package when there's no need for it. It's a waste of time for package maintainer, and users who have to download the new version, etc. We're not really concerned by branches, all we care is if there's a new tag to be packaged. Cheers, Thomas Goirand (zigo) __ 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] [all] [release] How to handle "stable" deliverables releases
Option 2 for me. And the option switch to independant is IMO just fine. __ 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] [all] [release] How to handle "stable" deliverables releases
Excerpts from Zane Bitter's message of 2018-06-12 17:52:24 -0400: > On 12/06/18 11:41, Michael Johnson wrote: > > I think we should continue with option 1. > > > > It is an indicator that a project is active in OpenStack and is > > explicit about which code should be used together. > > > > Both of those statements hold no technical water, but address the > > "human" factor of "What is OpenStack?", "What do I need to deploy?", > > "What is an active project and what is not?", and "How do we advertise > > what OpenStack can provide?". > > There's a strong argument that that makes sense for services. Although > in practice I'm doubtful that very many services could get through a > whole cycle without _any_ patches and still be working at the end of it. > (Incidentally, does the release tooling check that the gate still passes > at the time of release, even if it has been months since the last patch > merged?) > > It's not clear that it still makes sense for libraries though, and in > practice that's what this process will mostly apply to. (I tend to agree > with others in favouring 2, although the release numbering required to > account for possible future backports does leave something to be desired.) > > >>> One caveat with this model is that we need to be careful with version > >>> numbers. Imagine a library that did a 1.18.0 release for queens (which > >>> stable/queens is created from). Nothing happens in Rocky, so we create > >>> stable/rocky from the same 1.18.0 release. Same in Stein, so we create > >>> stable/stein from the same 1.18.0 release. During the Telluride[1] cycle > >>> some patches land and we want to release that. In order to leave room > >>> for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0, > >>> and go directly to 1.20.0. I think we can build release checks to ensure > >>> that, but that's something to keep in mind. > > Would another option be to release T as 1.19.0 and use 1.18.1.0 and > 1.18.2.0 for stable/rocky and stable/stein, respectively? There's no > *law* that says version numbers can only have 3 components, right? ;) We have interpreted PEP 440 and SemVer together to mean that regular versions have 3 parts and pre-release versions have a 4th part. That's up for debate, but my counter argument to changing it is that it will require quite a bit of tooling changes to support something other than what we have today, and I think it's going to be easier to build the thing that verifies we're using the right version numbers by counting stable branches. We have to do that verification anyway, so we might as well just do it for 3 part version numbers. 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] [all] [release] How to handle "stable" deliverables releases
On 12/06/18 11:41, Michael Johnson wrote: I think we should continue with option 1. It is an indicator that a project is active in OpenStack and is explicit about which code should be used together. Both of those statements hold no technical water, but address the "human" factor of "What is OpenStack?", "What do I need to deploy?", "What is an active project and what is not?", and "How do we advertise what OpenStack can provide?". There's a strong argument that that makes sense for services. Although in practice I'm doubtful that very many services could get through a whole cycle without _any_ patches and still be working at the end of it. (Incidentally, does the release tooling check that the gate still passes at the time of release, even if it has been months since the last patch merged?) It's not clear that it still makes sense for libraries though, and in practice that's what this process will mostly apply to. (I tend to agree with others in favouring 2, although the release numbering required to account for possible future backports does leave something to be desired.) One caveat with this model is that we need to be careful with version numbers. Imagine a library that did a 1.18.0 release for queens (which stable/queens is created from). Nothing happens in Rocky, so we create stable/rocky from the same 1.18.0 release. Same in Stein, so we create stable/stein from the same 1.18.0 release. During the Telluride[1] cycle some patches land and we want to release that. In order to leave room for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0, and go directly to 1.20.0. I think we can build release checks to ensure that, but that's something to keep in mind. Would another option be to release T as 1.19.0 and use 1.18.1.0 and 1.18.2.0 for stable/rocky and stable/stein, respectively? There's no *law* that says version numbers can only have 3 components, right? ;) cheers, Zane. __ 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] [all] [release] How to handle "stable" deliverables releases
Excerpts from Michael Johnson's message of 2018-06-12 08:41:57 -0700: > I think we should continue with option 1. > > It is an indicator that a project is active in OpenStack and is > explicit about which code should be used together. > > Both of those statements hold no technical water, but address the > "human" factor of "What is OpenStack?", "What do I need to deploy?", > "What is an active project and what is not?", and "How do we advertise > what OpenStack can provide?". I don't expect for oslo.i18n to see any patches during Stein, but it is still maintained. Is it still part of OpenStack under this definition? > > I think 2 and 3 will just lead to confusion and frustration for folks. > > Michael > On Mon, Jun 11, 2018 at 7:50 AM Doug Hellmann wrote: > > > > Excerpts from Thierry Carrez's message of 2018-06-11 11:53:52 +0200: > > > Hi everyone, > > > > > > As some of the OpenStack deliverables get more mature, we need to adjust > > > our release policies to best handle the case of deliverables that do not > > > need to be updated that much. This discussion started with how to handle > > > those "stable" libraries, but is actually also relevant for "stable" > > > services. > > > > > > Our current models include cycle-tied models (with-intermediary, > > > with-milestones, trailing) and a purely cycle-independent model. Main > > > OpenStack deliverables (the service components that you can deploy to > > > build an OpenStack cloud) are all "released" on a cycle. Libraries are > > > typically maintained per-cycle as well. What happens if no change is > > > pushed to a service or library during a full cycle ? What should we do > > > then ? > > > > > > Options include: > > > > > > 1/ Force artificial releases, even if there are no changes > > > > > > This is the current state. It allows to reuse the exact same process, > > > but creates useless churn and version number confusion. > > > > > > 2/ Do not force releases, but still create branches from latest releases > > > > > > In this variant we would not force an artificial re-release, but we > > > would still create a branch from the last available release, in order to > > > be able to land future patches and do bugfix or security releases as > > > needed. > > > > > > 2bis/ Like 2, but only create the branch when needed > > > > > > Same as the previous one, except that rather than proactively create the > > > stable branch around release time, we'd wait until the branch is > > > actually needed to create it. > > > > > > 3/ Do not force releases, and reuse stable branches from cycle to cycle > > > > > > In this model, if there is no change in a library in Rocky, stable/rocky > > > would never be created, and stable/queens would be used instead. Only > > > one branch would get maintained for the 2 cycles. While this reduces the > > > churn, it's a bit complex to wrap your head around the consequences, and > > > measure how confusing this could be in practice... > > > > > > 4/ Stop worrying about stable branches at all for those "stable" things > > > > > > The idea here would be to stop doing stable branches for those things > > > that do not release that much anymore. This could be done by switching > > > them to the "independent" release model, or to a newly-created model. > > > While good for "finished" deliverables, this option could create issues > > > for things that are inactive for a couple cycles and then pick up > > > activity again -- switching back to being cycle-tied would likely be > > > confusing. > > > > > > > > > My current preference is option 2. > > > > > > It's a good trade-off which reduces churn while keeping a compatibility > > > with the system used for more active components. Compared to 2bis, it's > > > a bit more work (although done in one patch during the release process), > > > but creating the branches in advance means they are ready to be used > > > when someone wants to backport something there, likely reducing process > > > pain. > > > > > > One caveat with this model is that we need to be careful with version > > > numbers. Imagine a library that did a 1.18.0 release for queens (which > > > stable/queens is created from). Nothing happens in Rocky, so we create > > > stable/rocky from the same 1.18.0 release. Same in Stein, so we create > > > stable/stein from the same 1.18.0 release. During the Telluride[1] cycle > > > some patches land and we want to release that. In order to leave room > > > for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0, > > > and go directly to 1.20.0. I think we can build release checks to ensure > > > that, but that's something to keep in mind. > > > > > > Thoughts ? > > > > > > [1] It's never too early to campaign for your favorite T name > > > > Although I originally considered it separate, reviewing your summary > > I suspect option 2bis is most likely to turn into option 3, in > > practice. > > > > I think having the choice between options 2 and switching to an > >
Re: [openstack-dev] [all] [release] How to handle "stable" deliverables releases
On Mon, Jun 11, 2018 at 2:53 AM, Thierry Carrez wrote: > > 2bis/ Like 2, but only create the branch when needed > > Same as the previous one, except that rather than proactively create the > stable branch around release time, we'd wait until the branch is actually > needed to create it. > This is basically openstack-chef right now, from a natural progression over time. In ye olden dayes, we were able to branch pretty soon after the RDO and Ubuntu packages stabilized. Now, due to time needed and engagement, it's an informal poll of the developer team to see who objects or sees something showstopping, then carrying on with creating the stable branch and releasing the artifacts to Supermarket. __ 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] [all] [release] How to handle "stable" deliverables releases
I think we should continue with option 1. It is an indicator that a project is active in OpenStack and is explicit about which code should be used together. Both of those statements hold no technical water, but address the "human" factor of "What is OpenStack?", "What do I need to deploy?", "What is an active project and what is not?", and "How do we advertise what OpenStack can provide?". I think 2 and 3 will just lead to confusion and frustration for folks. Michael On Mon, Jun 11, 2018 at 7:50 AM Doug Hellmann wrote: > > Excerpts from Thierry Carrez's message of 2018-06-11 11:53:52 +0200: > > Hi everyone, > > > > As some of the OpenStack deliverables get more mature, we need to adjust > > our release policies to best handle the case of deliverables that do not > > need to be updated that much. This discussion started with how to handle > > those "stable" libraries, but is actually also relevant for "stable" > > services. > > > > Our current models include cycle-tied models (with-intermediary, > > with-milestones, trailing) and a purely cycle-independent model. Main > > OpenStack deliverables (the service components that you can deploy to > > build an OpenStack cloud) are all "released" on a cycle. Libraries are > > typically maintained per-cycle as well. What happens if no change is > > pushed to a service or library during a full cycle ? What should we do > > then ? > > > > Options include: > > > > 1/ Force artificial releases, even if there are no changes > > > > This is the current state. It allows to reuse the exact same process, > > but creates useless churn and version number confusion. > > > > 2/ Do not force releases, but still create branches from latest releases > > > > In this variant we would not force an artificial re-release, but we > > would still create a branch from the last available release, in order to > > be able to land future patches and do bugfix or security releases as needed. > > > > 2bis/ Like 2, but only create the branch when needed > > > > Same as the previous one, except that rather than proactively create the > > stable branch around release time, we'd wait until the branch is > > actually needed to create it. > > > > 3/ Do not force releases, and reuse stable branches from cycle to cycle > > > > In this model, if there is no change in a library in Rocky, stable/rocky > > would never be created, and stable/queens would be used instead. Only > > one branch would get maintained for the 2 cycles. While this reduces the > > churn, it's a bit complex to wrap your head around the consequences, and > > measure how confusing this could be in practice... > > > > 4/ Stop worrying about stable branches at all for those "stable" things > > > > The idea here would be to stop doing stable branches for those things > > that do not release that much anymore. This could be done by switching > > them to the "independent" release model, or to a newly-created model. > > While good for "finished" deliverables, this option could create issues > > for things that are inactive for a couple cycles and then pick up > > activity again -- switching back to being cycle-tied would likely be > > confusing. > > > > > > My current preference is option 2. > > > > It's a good trade-off which reduces churn while keeping a compatibility > > with the system used for more active components. Compared to 2bis, it's > > a bit more work (although done in one patch during the release process), > > but creating the branches in advance means they are ready to be used > > when someone wants to backport something there, likely reducing process > > pain. > > > > One caveat with this model is that we need to be careful with version > > numbers. Imagine a library that did a 1.18.0 release for queens (which > > stable/queens is created from). Nothing happens in Rocky, so we create > > stable/rocky from the same 1.18.0 release. Same in Stein, so we create > > stable/stein from the same 1.18.0 release. During the Telluride[1] cycle > > some patches land and we want to release that. In order to leave room > > for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0, > > and go directly to 1.20.0. I think we can build release checks to ensure > > that, but that's something to keep in mind. > > > > Thoughts ? > > > > [1] It's never too early to campaign for your favorite T name > > Although I originally considered it separate, reviewing your summary > I suspect option 2bis is most likely to turn into option 3, in > practice. > > I think having the choice between options 2 and switching to an > independent release model (maybe only for libraries) is going to > be best, at least to start out. > > Stein will be the first series where we have to actually deal with > this, so we can see how it goes and discuss alternatives if we run > into issues. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe:
Re: [openstack-dev] [all] [release] How to handle "stable" deliverables releases
Excerpts from Thierry Carrez's message of 2018-06-11 11:53:52 +0200: > Hi everyone, > > As some of the OpenStack deliverables get more mature, we need to adjust > our release policies to best handle the case of deliverables that do not > need to be updated that much. This discussion started with how to handle > those "stable" libraries, but is actually also relevant for "stable" > services. > > Our current models include cycle-tied models (with-intermediary, > with-milestones, trailing) and a purely cycle-independent model. Main > OpenStack deliverables (the service components that you can deploy to > build an OpenStack cloud) are all "released" on a cycle. Libraries are > typically maintained per-cycle as well. What happens if no change is > pushed to a service or library during a full cycle ? What should we do > then ? > > Options include: > > 1/ Force artificial releases, even if there are no changes > > This is the current state. It allows to reuse the exact same process, > but creates useless churn and version number confusion. > > 2/ Do not force releases, but still create branches from latest releases > > In this variant we would not force an artificial re-release, but we > would still create a branch from the last available release, in order to > be able to land future patches and do bugfix or security releases as needed. > > 2bis/ Like 2, but only create the branch when needed > > Same as the previous one, except that rather than proactively create the > stable branch around release time, we'd wait until the branch is > actually needed to create it. > > 3/ Do not force releases, and reuse stable branches from cycle to cycle > > In this model, if there is no change in a library in Rocky, stable/rocky > would never be created, and stable/queens would be used instead. Only > one branch would get maintained for the 2 cycles. While this reduces the > churn, it's a bit complex to wrap your head around the consequences, and > measure how confusing this could be in practice... > > 4/ Stop worrying about stable branches at all for those "stable" things > > The idea here would be to stop doing stable branches for those things > that do not release that much anymore. This could be done by switching > them to the "independent" release model, or to a newly-created model. > While good for "finished" deliverables, this option could create issues > for things that are inactive for a couple cycles and then pick up > activity again -- switching back to being cycle-tied would likely be > confusing. > > > My current preference is option 2. > > It's a good trade-off which reduces churn while keeping a compatibility > with the system used for more active components. Compared to 2bis, it's > a bit more work (although done in one patch during the release process), > but creating the branches in advance means they are ready to be used > when someone wants to backport something there, likely reducing process > pain. > > One caveat with this model is that we need to be careful with version > numbers. Imagine a library that did a 1.18.0 release for queens (which > stable/queens is created from). Nothing happens in Rocky, so we create > stable/rocky from the same 1.18.0 release. Same in Stein, so we create > stable/stein from the same 1.18.0 release. During the Telluride[1] cycle > some patches land and we want to release that. In order to leave room > for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0, > and go directly to 1.20.0. I think we can build release checks to ensure > that, but that's something to keep in mind. > > Thoughts ? > > [1] It's never too early to campaign for your favorite T name Although I originally considered it separate, reviewing your summary I suspect option 2bis is most likely to turn into option 3, in practice. I think having the choice between options 2 and switching to an independent release model (maybe only for libraries) is going to be best, at least to start out. Stein will be the first series where we have to actually deal with this, so we can see how it goes and discuss alternatives if we run into issues. 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] [all] [release] How to handle "stable" deliverables releases
On Mon, 11 Jun 2018, Thierry Carrez wrote: 2/ Do not force releases, but still create branches from latest releases In this variant we would not force an artificial re-release, but we would still create a branch from the last available release, in order to be able to land future patches and do bugfix or security releases as needed. This one seems best because of: creating the branches in advance means they are ready to be used when someone wants to backport something there, likely reducing process pain. Really glad to see this happening. We need to make sure that we don't accidentally make low-activity because mature and stable look the same as low-activity because dead. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ 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] [all] [release] How to handle "stable" deliverables releases
Hi everyone, As some of the OpenStack deliverables get more mature, we need to adjust our release policies to best handle the case of deliverables that do not need to be updated that much. This discussion started with how to handle those "stable" libraries, but is actually also relevant for "stable" services. Our current models include cycle-tied models (with-intermediary, with-milestones, trailing) and a purely cycle-independent model. Main OpenStack deliverables (the service components that you can deploy to build an OpenStack cloud) are all "released" on a cycle. Libraries are typically maintained per-cycle as well. What happens if no change is pushed to a service or library during a full cycle ? What should we do then ? Options include: 1/ Force artificial releases, even if there are no changes This is the current state. It allows to reuse the exact same process, but creates useless churn and version number confusion. 2/ Do not force releases, but still create branches from latest releases In this variant we would not force an artificial re-release, but we would still create a branch from the last available release, in order to be able to land future patches and do bugfix or security releases as needed. 2bis/ Like 2, but only create the branch when needed Same as the previous one, except that rather than proactively create the stable branch around release time, we'd wait until the branch is actually needed to create it. 3/ Do not force releases, and reuse stable branches from cycle to cycle In this model, if there is no change in a library in Rocky, stable/rocky would never be created, and stable/queens would be used instead. Only one branch would get maintained for the 2 cycles. While this reduces the churn, it's a bit complex to wrap your head around the consequences, and measure how confusing this could be in practice... 4/ Stop worrying about stable branches at all for those "stable" things The idea here would be to stop doing stable branches for those things that do not release that much anymore. This could be done by switching them to the "independent" release model, or to a newly-created model. While good for "finished" deliverables, this option could create issues for things that are inactive for a couple cycles and then pick up activity again -- switching back to being cycle-tied would likely be confusing. My current preference is option 2. It's a good trade-off which reduces churn while keeping a compatibility with the system used for more active components. Compared to 2bis, it's a bit more work (although done in one patch during the release process), but creating the branches in advance means they are ready to be used when someone wants to backport something there, likely reducing process pain. One caveat with this model is that we need to be careful with version numbers. Imagine a library that did a 1.18.0 release for queens (which stable/queens is created from). Nothing happens in Rocky, so we create stable/rocky from the same 1.18.0 release. Same in Stein, so we create stable/stein from the same 1.18.0 release. During the Telluride[1] cycle some patches land and we want to release that. In order to leave room for rocky and stein point releases, we need to skip 1.18.1 and 1.19.0, and go directly to 1.20.0. I think we can build release checks to ensure that, but that's something to keep in mind. Thoughts ? [1] It's never too early to campaign for your favorite T name -- Thierry Carrez (ttx) __ 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
