Skip to content

Commit aec9915

Browse files
jrcain-usgsjrcain-usgs
authored
new release schedule (#153)
* new release schedule draft * Update Types, Cadence, Git Illustration * order, notes * spelling verison -> version * minor patch release notes * remove old release schedule * rename new release schedule to relplace old * "major" * prod tabs * Add preparation step, clarify branches * update step numbers, move AWS version step later * Feeder vs Release branch * notice * 'major' releases * 'new version' * isis release git graph colors * production spelling * changes after discussion - condensing branches * going from RC1 to 2, branch naming, local branches
1 parent a142f07 commit aec9915

File tree

2 files changed

+241
-83
lines changed

2 files changed

+241
-83
lines changed

‎docs/how-to-guides/software-management/isis-release-schedule.md‎

Lines changed: 127 additions & 44 deletions
Original file line numberDiff line numberDiff line change
@@ -1,44 +1,127 @@
1-
# ISIS Release Schedule
2-
This document describes the cadence and schedule for ISIS releases.
3-
4-
## Release Cadence
5-
Releases and development of ISIS3 follows a time based schedule with a new release occurring every three months. Below, we illustrate a sample four month snapshot of software development.
6-
7-
<figure markdown>
8-
![Release Cadence](../../../assets/release-schedule/release_schedule.png)
9-
<figcaption>Example of ISIS Release Cadence</figcaption>
10-
</figure>
11-
12-
13-
14-
At the start of Month 1, a Release Candidate (RC1) is created from the `dev` branch of our GitHub repository. This RC contains all development from the previous (not shown) three months. RC1 is made publicly available as both a labelled branch and via our Anaconda.org (conda) [download page](https://anaconda.org/usgs-astrogeology/isis). During Month 1, we solicit input and testing from the broader community. Any issues identified in RC1 will be fixed during Month 1. At the conclusion of Month 1, the release is packaged and the next ISIS3 release is made available for the general public using Anaconda.org (and the default `main` label).
15-
16-
During Month 1 through Month 3, we continue with new feature development for RC2. At the start of Month 4, we repeat the same release candidate and release process as described above.
17-
18-
## Feature Freeze
19-
When a Release Candidate is branched from the `dev` branch, a feature freeze is put into effect. Any feature additions that occur after a release candidate has been branched will be included in a future RC (and release). In other words, features added prior to the creation of a RC will be included in the next release. The only instances where this may not hold true is if significant, previously unidentified issues are identified during the testing of a RC that are associated with a new feature addition. In that case, we would back out the feature and recreate the RC.
20-
21-
## Release
22-
As described above, we will release on a three month cadence. Releases will be labelled via GitHub for those users that wish to build from source. Additionally, releases will be uploaded to our Anaconda.org [repository](https://anaconda.org/usgs-astrogeology/isis) for `conda` installation.
23-
24-
## Release Schedule
25-
| Version # / Label | Type | Date |
26-
|-------------------|------|------------|
27-
| 4.3.0 | Release | 10.26.20 |
28-
| 4.4.0 | Release | 2.8.21 |
29-
| 5.0.0_RC | Release Candidate | 4.1.21 |
30-
| 5.0.0 | Release | 4.27.21 |
31-
| 6.0.0_RC | Release Candidate | 8.1.21 |
32-
| 6.0.0 | Release | 7.25.21 |
33-
| 7.0.0_RC1 | Release Candidate | 3.4.22 |
34-
| 7.0.0_RC2 | Release Candidate | 4.15.22 |
35-
| 7.0.0 | Release | 5.2.22 |
36-
| 7.1.0_RC | Release Candidate | 8.1.22 |
37-
| 7.1.0 | Release | 9.20.22 |
38-
| 7.2.0_RC | Release Candidate | 11.7.22 |
39-
| 7.2.0 | Release | 03.21.23 |
40-
| 8.0.0 | LTS Release | 8.2.23 |
41-
| 8.1.0 | Release | 11.2.23 |
42-
| 8.2.0 | Release | 04.27.24 |
43-
| 9.0.0 | LTS Release | 8.2.24 |
44-
| 8.0.* | LTS End of Life | 2.2.25 |
1+
# ISIS Release Schedule and Release Types
2+
3+
#### Key Differences
4+
5+
| Release Type | Supported | RC | Versioning | Updates | MAJOR | MINOR | PATCH |
6+
|--------------|-----------|----|------------|-----------|-------|-------|-------|
7+
| LTS | 18 months | N | semver | biweekly | N | N | Y |
8+
| Production | 12 months | N | semver | quarterly | N | Y | Y |
9+
| Dev | 2 weeks | N | date-based | biweekly | Y | Y | Y |
10+
| New Version | 18 months | Y | semver | yearly | Y | Y | Y |
11+
12+
## Release Types
13+
14+
ISIS has four types of releases:
15+
16+
- **LTS** - Most Stable. Gets *Bugfixes* but not new *Features* between major releases.
17+
- **Production** - Gets new *Features* and *Bugfixes* but not *Breaking Updates*.
18+
- **Dev** - First to get new *Features*, including *Breaking Updates*.
19+
- **New Version**\* - Updates all other release types with *Breaking Updates*.
20+
21+
!!! note "Notes"
22+
23+
**Production is the default version of ISIS.**
24+
If you install the `main` version of ISIS, or do not specify a label,
25+
you will get the production version.
26+
27+
**Releases can be found** in the
28+
[ISIS GitHub repo](https://github.com/DOI-USGS/ISIS3/releases)
29+
and on our [conda channel](https://anaconda.org/usgs-astrogeology/isis).
30+
31+
The **Dev** version ***does not get a release on GitHub***,
32+
but can be found in the [dev branch](https://github.com/DOI-USGS/ISIS3/tree/dev) of the repo.
33+
It **does** get a release on our conda channel every two weeks.
34+
35+
\* The **New Version** release is a special type of LTS release: The ***first LTS release*** of any major version of ISIS (i.e, 9.0.0 LTS, 10.0.0 LTS).
36+
37+
## Types of Updates
38+
39+
Outlined in [Semantic Versioning (external)](https://semver.org), we categorize updates into three types:
40+
41+
- **Major** (breaking) updates can break a workflow that functioned in a previous version.
42+
- **Minor** (feature) updates add features but shouldn't break previously working workflows.
43+
- **Patch** (bugfix) updates fix bugs, but don't add features or change functional workflows.
44+
45+
46+
## Update Cadence and Type
47+
48+
- **Yearly**: ISIS **LTS** and **Production** releases get *Major* updates.
49+
- **Quarterly**: The ISIS **Production** release gets *Minor* and *Patch* updates.
50+
- **Biweekly**:
51+
- The **Dev** release may get *Major* updates.
52+
- The **LTS** release gets *Patch* updates only.
53+
54+
## Flow of Updates
55+
56+
#### Flow of MAJOR, MINOR, and PATCH updates from Dev to LTS and Production
57+
58+
- ***Patch*** updates are merged from Dev into **LTS** and **Production** versions of ISIS.
59+
- ***Minor*** updates are merged into the **Production** version.
60+
- ***Major*** updates remain only in **Dev** ISIS, until the yearly RC and LTS Release.
61+
62+
``` mermaid
63+
%%{init: { 'logLevel': 'debug', 'theme': 'base', 'themeVariables': {'git0': '#d00', 'git1': '#096', 'git2': '#07e', 'tagLabelBorder': '#ea0', 'gitInv1': '#fc0'}, 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'Dev'}} }%%
64+
gitGraph
65+
66+
commit id:"2024.24"
67+
68+
branch LTS
69+
checkout LTS
70+
commit id:"9.0.0 RC"
71+
commit id:"9.0.0 LTS" type: HIGHLIGHT tag: "New Ver."
72+
73+
branch Prod
74+
checkout Prod
75+
commit id:"9.0.0 Prod"
76+
77+
checkout LTS
78+
checkout Dev
79+
commit id:"2025.1 (PATCH)"
80+
81+
checkout LTS
82+
merge Dev id:"9.0.1 LTS"
83+
84+
checkout Prod
85+
merge Dev id:"9.0.1 Prod"
86+
87+
checkout Dev
88+
commit id:"2025.2 (MINOR)"
89+
90+
checkout Prod
91+
merge Dev id:"9.1.0 Prod"
92+
93+
checkout Dev
94+
commit id:"2025.3 (MAJOR)"
95+
96+
checkout LTS
97+
merge Dev id:"10.0.0 RC"
98+
commit id:"10.0.0 LTS" type: HIGHLIGHT tag: "New Ver."
99+
100+
checkout Dev
101+
commit id:"2025.4"
102+
```
103+
104+
105+
## Release Candidates (New Versions of ISIS)
106+
107+
For the yearly New Version Release (i.e, from ***8***.x.x → ***9***.0.0),
108+
there is first a *Release Candidate* to test new features before they are included.
109+
While the RC is out, we solicit feedback and testing from the community,
110+
and identify and fix issues before making an Major ISIS release.
111+
112+
This major release will flow to LTS and Prod channels.
113+
114+
### RC Feature Freeze
115+
116+
When a Release Candidate (RC) is branched from the `dev` branch, a feature freeze is put into effect.
117+
Any feature additions that occur after an RC has been branched will be included in a future RC (and release).
118+
A feature added before the creation of an RC will be included in the next major update,
119+
unless issues are found with the new feature. In that case, the feature will be removed and the RC recreated.
120+
121+
## Minor/Patch Releases
122+
123+
For subsequent releases within the same major version
124+
(i.e, 8.***2***.0 → 8.***3***.0, 9.0.***1*** → 9.0.***2***),
125+
there is no release candidate.
126+
Updates are accumulated on a release-feeder branch for LTS or Production,
127+
then released.

0 commit comments

Comments
 (0)