From 2eed572b1bd37ca47baf991accf8911edf690a7c Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Fri, 16 Jan 2026 13:47:56 -0700 Subject: [PATCH 1/4] remove dated release info Signed-off-by: Larry Peterson --- index.rst | 10 ---- release/2.0.rst | 6 --- release/2.1.rst | 6 --- release/process.rst | 118 -------------------------------------------- 4 files changed, 140 deletions(-) delete mode 100644 release/2.0.rst delete mode 100644 release/2.1.rst delete mode 100644 release/process.rst diff --git a/index.rst b/index.rst index e150c77..0f4002b 100644 --- a/index.rst +++ b/index.rst @@ -56,13 +56,3 @@ operations/slice operations/metering operations/monitor - -.. toctree:: - :maxdepth: 2 - :caption: Releases - :hidden: - :glob: - - release/2.0.rst - release/2.1.rst - release/process.rst diff --git a/release/2.0.rst b/release/2.0.rst deleted file mode 100644 index de6563f..0000000 --- a/release/2.0.rst +++ /dev/null @@ -1,6 +0,0 @@ -Aether 2.0 Release -================== - -.. note:: Aether 2.0 is no longer supported. Its Guide is archived - `here `__. - diff --git a/release/2.1.rst b/release/2.1.rst deleted file mode 100644 index cda0ea1..0000000 --- a/release/2.1.rst +++ /dev/null @@ -1,6 +0,0 @@ -Aether 2.1 Release -================== - -.. note:: Aether 2.1 is being deprecated. Its Guide is archived - `here `__. - diff --git a/release/process.rst b/release/process.rst deleted file mode 100644 index 99e65e1..0000000 --- a/release/process.rst +++ /dev/null @@ -1,118 +0,0 @@ -Release Process -=============== - -Prerequisites -------------- - -Aether makes the following assumptions about the components are included in a -release: - -Git Tags -"""""""" - -Code receives Git tags as a part of the CI process - -* Tag content comes from a **VERSION** file within the repo, and tags are - created only the version is a SemVer released version (example: ``1.2.3``, no - ``-dev`` or ``-rc`` extensions) - -* Tagging is *only done by the CI system* (Jenkins), which pushes tags to git - repos after a submit/merge of code which changes the **VERSION** file. - -* CI system enforces tag uniqueness - no two commits have the same released - version tags. - - * You can't re-release or "fix" a version that has problem - make a new - version with fixes in it. - -Docker Container Images -""""""""""""""""""""""" - -All docker images are tagged based on their git tags. - -* For released versions, the CI system should prevent a Dockerfile from - referencing a parent containers that are a moving target, such as ``latest`` - or ``master``. - - * This allows a container to be rebuilt given an arbitrary git commit with - fair confidence that it will result in the same code in the container. - -* Official images are only pushed to registries by the CI system - - * Increases repeatability of the process, and prevents human accidents. - -Helm Charts -""""""""""" - -* Each chart may only contain references to released, SemVer tagged container images - - * Chart CI process must check that a chart version is unique - a chart can't - be created with the same version twice. This should be done against the - chart repo. - -Release Steps -------------- - -All Helm charts are checked that the containers they use have a SemVer version -tag - -A branch is created on the Helm charts repo, with the abbreviated name of the -release - for example **aether-2.1**. - -To allow for future patches to go into the repo in a way that does not conflict -with the version branch, each component repo's **VERSION** file should have it's -minor version increased. (ex: 1.2.n to 1.3.0-dev, so future 1.3.n+1 component -release can easily be created). - -The same should be done on Helm charts in the chart repos post release, but the -versions there shouldn't include a ``-dev`` suffix because chart publishing -requires that every new chart version be unique and unsuffixed SemVer is a -more consistent release numbering pattern. - -Finally, the ``aether-helm-charts`` repo overall **VERSION** should also be incremented -to the next minor version (2.2.0-dev) on the **master** branch, so all 2.1.x -releases of the overall charts repo will happen on the **aether-2.1** branch. - -Creating Releases on the 2.1.x Branch -""""""""""""""""""""""""""""""""""""" - -If a fix is needed only to the helm charts: - -1. Make the fix on the master branch of aether-helm-charts (assuming that it is - required in both places). - -2. After the master tests pass, manually cherry-pick the fix to the **aether-2.1** - branch (the Chart version would be different, requiring the manual step). - -3. Cherry-picked patchsets on that branch will be checked by the **aether-2.1** - branch of tests. - -4. When it passes, submitting the change will make a new 2.1.x release - -5. Update the documentation to reflect the chart changes, a description of the - changes m, and increment the tag on the docs from 2.1.n to 2.1.n+1, to - reflect the patch change. - -6. If all the charts are updated and working correctly, create a new charts - point release by increasing the 2.1.n **VERSION** file in the - aether-helm-charts repo. This should be the same as the version in the - documentation. Immediately make another patch that returns the - ``aether-helm-charts`` **VERSION** to 2.1.n+1-dev, so that development - patches can continue on that branch. - -If a fix is needed to the components/containers that are included by the helm charts: - -1. Develop a fix to the issue on the master branch, get it approved after - passing master tests. - -2. If it doesn't exist, create an **aether-2.1** branch on the component repo, - starting at the commit where the **VERSION** of the component used in 2.1 was - created - this is known as "lazy branching". - - -3. Manually cherry-pick to the **aether-2.1** branch of the component, incrementing - the patch version, and test with the **aether-2.1** version of - aether-system-tests and helm charts. - -4. Update helm charts and go through the helm chart update process above - From 46e398f60623c857ccce24d54fcb3dba4f36e77e Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Fri, 16 Jan 2026 13:51:51 -0700 Subject: [PATCH 2/4] fixed old url Signed-off-by: Larry Peterson --- onramp/ref.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/onramp/ref.rst b/onramp/ref.rst index d98f001..060741b 100644 --- a/onramp/ref.rst +++ b/onramp/ref.rst @@ -43,36 +43,36 @@ repo. The groovy files can be found in the `aether-jenkins - N/A - Physical 5G small cell radio connected to 5G Core; demonstrated with MOSO CANOPY 5G indoor small cell. - * - `Multiple UPFs `__ + * - `Multiple UPFs `__ - `main-upf.yml` - `upf.groovy` - Instantiate multiple UPFs and bind them to distinct Slices. - * - `SD-RAN (RIC) `__ + * - `SD-RAN (RIC) `__ - `main-sdran.yml` - `sdran.groovy` - SD-RAN (with RANSIM traffic) connected to 5G Core. - * - `UERANSIM `__ + * - `UERANSIM `__ - `main-ueransim.yml` - `ueransim.groovy` - UERANSIM (with ``iperf`` traffic) connected to 5G Core. - * - `Physical eNB `__ + * - `Physical eNB `__ - `main-eNB.yml` - N/A - Physical 4G small cell radio connected to 4G Core; demonstrated with Sercomm indoor small cell. - * - `SR-IOV/DPDK `__ + * - `SR-IOV/DPDK `__ - `main-sriov.yml` - N/A - 5G Core with SR-IOV and DPDK optimizations enabled for User Plane. - * - `OAI 5G RAN `__ + * - `OAI 5G RAN `__ - `main-oai.yml` - `oai.groovy` - OAI software radio connected to 5G Core. - * - `srsRAN 5G `__ + * - `srsRAN 5G `__ - `main-srsran.yml` - `srsran.groovy` - srsRAN software radio connected to 5G Core. - * - `N3IWF `__ + * - `N3IWF `__ - `main-n3iwf.yml` - N/A - N3IWF connected to 5G Core to provide internet access to non-3GPP devices. From 00fa1732525de682be00ee653ee18fe9dea5ea28 Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Fri, 16 Jan 2026 13:57:40 -0700 Subject: [PATCH 3/4] fix broken url Signed-off-by: Larry Peterson --- operations/subscriber.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/operations/subscriber.rst b/operations/subscriber.rst index b3beb92..173c975 100644 --- a/operations/subscriber.rst +++ b/operations/subscriber.rst @@ -32,7 +32,7 @@ Operations team. This subscriber-related detail is configured via the SIM Management application, ``simapp``. As described in the `OnRamp Guide -`__, +`__, the ``subscribers`` section of the values file needs to be edited to include the new Device IMSIs: From bc28d9df90a0bfbd2a10542e3ca875bc61a9d0ff Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Fri, 16 Jan 2026 14:00:30 -0700 Subject: [PATCH 4/4] fix broken url Signed-off-by: Larry Peterson --- onramp/roc.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/onramp/roc.rst b/onramp/roc.rst index 4c3a091..0e84c35 100644 --- a/onramp/roc.rst +++ b/onramp/roc.rst @@ -129,4 +129,4 @@ secure login feature. .. admonition:: Further Reading `Aether Operations - `__. + `__.