| Message ID | 20231123123807.38847-4-amusil@redhat.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Allow to use different container images per branch | expand |
| Context | Check | Description |
|---|---|---|
| ovsrobot/apply-robot | success | apply and check: success |
| ovsrobot/github-robot-_Build_and_Test | success | github build: passed |
| ovsrobot/github-robot-_ovn-kubernetes | success | github build: passed |
On 11/23/23 13:38, Ales Musil wrote: > Add note that one the patches after branching should > pin the container to the current LTS version so the > CI on that branch remains stable as long as possible. > > Signed-off-by: Ales Musil <amusil@redhat.com> > --- > Documentation/internals/release-process.rst | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst > index ec79fe48c..26d3f8d4d 100644 > --- a/Documentation/internals/release-process.rst > +++ b/Documentation/internals/release-process.rst > @@ -64,6 +64,10 @@ Scheduling`_ for the timing of each stage: > branch. Features to be added to release branches should be limited in scope > and risk and discussed on ovs-dev before creating the branch. > > + In order to keep the CI stable on the new release branch, the Ubuntu > + container should be pinned to the current LTS version in the Dockerfile > + e.g. registry.hub.docker.com/library/ubuntu:22.04. > + Should we already move stable branches to ubuntu:22.04? Regardless: Acked-by: Dumitru Ceara <dceara@redhat.com> > 3. When committers come to rough consensus that the release is ready, they > release the .0 release on its branch, e.g. 25.09.0 for branch-25.09. To > make the actual release, a committer pushes a signed tag named, e.g.
diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst index ec79fe48c..26d3f8d4d 100644 --- a/Documentation/internals/release-process.rst +++ b/Documentation/internals/release-process.rst @@ -64,6 +64,10 @@ Scheduling`_ for the timing of each stage: branch. Features to be added to release branches should be limited in scope and risk and discussed on ovs-dev before creating the branch. + In order to keep the CI stable on the new release branch, the Ubuntu + container should be pinned to the current LTS version in the Dockerfile + e.g. registry.hub.docker.com/library/ubuntu:22.04. + 3. When committers come to rough consensus that the release is ready, they release the .0 release on its branch, e.g. 25.09.0 for branch-25.09. To make the actual release, a committer pushes a signed tag named, e.g.
Add note that one the patches after branching should pin the container to the current LTS version so the CI on that branch remains stable as long as possible. Signed-off-by: Ales Musil <amusil@redhat.com> --- Documentation/internals/release-process.rst | 4 ++++ 1 file changed, 4 insertions(+)