You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@trafficserver.apache.org by zw...@apache.org on 2023/01/31 21:53:32 UTC
[trafficserver] branch master updated: Update the roadmap / branch management doc page (#9340)
This is an automated email from the ASF dual-hosted git repository.
zwoop pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/trafficserver.git
The following commit(s) were added to refs/heads/master by this push:
new ba45b075e Update the roadmap / branch management doc page (#9340)
ba45b075e is described below
commit ba45b075e5709b752a11fa38f13ce9bd2c1cb6fc
Author: Leif Hedstrom <zw...@apache.org>
AuthorDate: Tue Jan 31 14:53:24 2023 -0700
Update the roadmap / branch management doc page (#9340)
---
doc/release-notes/images/branch_mgmt.png | Bin 0 -> 31845 bytes
doc/release-notes/roadmap.en.rst | 86 +++++++++++++++++++------------
2 files changed, 54 insertions(+), 32 deletions(-)
diff --git a/doc/release-notes/images/branch_mgmt.png b/doc/release-notes/images/branch_mgmt.png
new file mode 100644
index 000000000..d24817da7
Binary files /dev/null and b/doc/release-notes/images/branch_mgmt.png differ
diff --git a/doc/release-notes/roadmap.en.rst b/doc/release-notes/roadmap.en.rst
index 7afb416ad..4c122686c 100644
--- a/doc/release-notes/roadmap.en.rst
+++ b/doc/release-notes/roadmap.en.rst
@@ -31,53 +31,75 @@ our `download page <https://trafficserver.apache.org/downloads>`_ to see the
current supported versions.
-For details on the actual developer release process, See
-
Versions, compatibility and schedules
-------------------------------------
-1. We promise to make 1 major release every two years, but the RM and
+1. We aim to make 1 major release every two years, but the RM and
community can of course make more as necessary.
-2. We only make releases off the LTS branches, which are cut every 2 years
- off the master branch.
-3. Master is always open, for any type of change (including incompatible
- changes). But don't break compatibility just for fun!
+2. We cut LTS major and minor releases striaght off the master branch.
+ We will make release branches in a timely manner before making any
+ release candidates.
+3. Master is always open for compatible changes.
4. Master is always stable, i.e. commits should be properly tested and
reviewed before committed to master.
-5. All releases are stable releases, following strict Semantic Versioning.
-6. Minor and patch releases are made at the discretion of the community and
+5. Incompatible changes must be made on the current ``-dev`` branch.
+6. All releases are stable releases, following strict Semantic Versioning.
+7. Minor and patch releases are made at the discretion of the community and
the RM.
-7. Minor releases can include new (small / safe) features, but must be
+8. Minor releases can include new (small / safe) features, but must be
compatible within the LTS major version.
-8. The LTS cycle, 4 years, does not reset when we make a minor release.
-9. The goal is that within a major LTS version, only one minor version is
- continuously supported. For example, if we have made a v9.1.2, and the
- RM makes a v9.2.0 release, do not expect any more releases of v9.1.x.
- The exception here would be serious issues, or security problems.
+9. The LTS cycle, approximately 4 years, does not reset when we make a minor
+ release.
+10. The goal is that within a major LTS version, only one minor version is
+ continuously supported. For example, if we have made a v9.1.2, and the
+ RM makes a v9.2.0 release, do not expect any more releases of v9.1.x.
+ The exception here would be serious issues, or security problems.
+
+Branch Management
+-----------------
+
+As of `v10.0.0`` and forward, we will cut all major and minor branches off
+the main branch (master). The ``-Dev`` branch will be used for incompatible
+changes, and will be merged into master when the next major release is
+in progress.
+
+.. figure:: images/branch_mgmt.png
+ :align: left
+
+The implication of this new process is that we will no longer cherry pick
+PRs from master to a release branch. Rather, each major and minor release
+is taken whole sale from the master branch. For managing your PRs, this means:
+
+1. You do not need to nominate your PR for a backport to a minor release, unless
+ the release branch has been cut. A goal here is that the release branches
+ are stable in preparation of the minor release, while master is still open.
+2. An exception for this are the older LTS releases and minor critical fixes.
+ For such changes, always nominate your PR for backport to those Projects.
+3. The default ``Milestone`` changes for every major and minor release. For
+ example, if the current LTS release is `10.0.1`, the milestone for all new
+ PRs will be `10.1.0` going forward.
+4. We will create tags on the master branch regularly, for coordinating testing
+ efforts. These are not releases!
+5. We will regularly (weekly) merge master to the current ``-Dev`` branch,
+ to keep them in sync.
+
+It is absolutely critical that everyone sets the ``Milestone`` and ``Project``
+fields appropriate in this process. This is how we will manage the releases!
Current Release Schedule and support
------------------------------------
+Master is currently targeted for our first `v10.0.x` release. When this branch
+is created, the new process kicks in and ``Milestones`` must follow the
+next minor release number (e.g. `10.1.0`).
+
.. figure:: images/roadmap.png
- :align: center
+ :align: left
**Note:** These are examples, only the first minor release number of each
major LTS branch is guaranteed to be made. The dates for point releases
are also for illustration.
-How?
-----
-
-As you can see, we no longer make any sort of development releases. Also,
-there's no longer a backport voting process! The latter means that all
-developers and users must make a higher commitment to reviewing changes as
-they go into master and the incompatible release branch. Other than that,
-it's pretty much business as usual, but easier for everyone involved.
-This git branch diagram shows an example how the git tree will be managed:
-
-.. figure:: images/git-versions.svg
- :align: center
-
Burning release numbers, or how our release process works
---------------------------------------------------------
@@ -109,9 +131,9 @@ Release Managers
======= ======= ========= =========== =========
Version Primary Secondary 1st Release Supported
======= ======= ========= =========== =========
-8.x Evan Leif 8/2018 1/2022
-9.x Leif Bryan 1/2020 1/2024
-10.x TBD TBD 1/2022 1/2026
+8.x Evan Leif 8/2018 3/2023
+9.x Evan Bryan 1/2020 3/2025
+10.x Leif Bryan 3/2023 3/2027
======= ======= ========= =========== =========