On 5/26/23 08:45, Dumitru Ceara wrote:
On 5/25/23 20:22, Mark Michelson wrote:
The OVN team has had no concrete policy regarding when releases are
made for a given version. In the past, new releases have been made only
when something critical has been found, meaning that most bug fixes
applied to a given OVN version never end up in a release.
This change proposes a monthly release per supported OVN version.
Signed-off-by: Mark Michelson <mmich...@redhat.com>
---
Documentation/internals/release-process.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/internals/release-process.rst
b/Documentation/internals/release-process.rst
index 1f4b90143..0287795dc 100644
--- a/Documentation/internals/release-process.rst
+++ b/Documentation/internals/release-process.rst
@@ -152,6 +152,12 @@ approximate:
| T + 6 | Sep 1, Mar 1, ... | Release version x.y.0 |
+---------------+---------------------+--------------------------------------+
+After the .0 release is created for a given OVN version, that version will have
+releases made every month until its support lifetime has concluded. If for some
+reason, no changes occur to a supported OVN version during a month, then no
+release will be made that month. Therefore, there is no guarantee about the
+exact number of releases to be expected for any given OVN version.
+
Release Calendar
----------------
It makes sense but (I think I may have mentioned this during an upstream
meeting) can we automate the process? It's going to be 2 patches per
release, 2 standard term releases + 2 LTS releases, release every month
=> 96 patches to ack throughout the year (unless my reasoning is wrong).
The basic mechanics of a release would be easy to automate. I already
use a script provided by Ilya to create the release commits, send them
to the mailing list, and merge the commits and create the tag. The
things that currently cannot be automated are:
1) Acks for release patches. We currently post the patches to the
mailing list and await acks before merging/tagging. We could potentially
agree as a project that these commits could just be automatically
created and pushed/tagged without developer acks.
2) Signing the tag. When I create OVN releases, I sign the tag with my
GPG key. I'm not sure what a good automated substitute for this would be.
3) Updating ovn.org. For .0 releases, I typically will go through all
the commits and keep a list of new features and performance
enhancements. I then write these up on the release page. Automating this
exact process would not be possible. However we could switch to a
changelog style where we list all the commits that went into a given
release. This would be easier to automate. For .1 releases, we shouldn't
have new features or performance improvements. We should only have bug
fixes. The changelog approach would fit for these types of releases well.
Regards,
Dumitru
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
