Release Cadence and Process

[JamesPolly-NCO]

We would like to cut a new tag/version on the standards with a regular cadence. "Tag"="Version" for this discussion.

Feedback is being requested on the following (and other ideas if not covered below):

• Cadence: How often will we regularly create a new tag/version?
  • Opening suggestion: every three months
• Approval for tags: Do we need an any approval process for creating new tags at the specified cadence?
  • Opening suggestion: No, all approval takes place at PR merge to latest step.
• Stable vs. Latest: Should we will continue to keep a stable (last cut tag) version that is referenced at the "stable" link, and a "latest" version that contains PRs merged since the most recently cut tag.
  • Opening suggestion: Yes.
• Tag/Version name: How will we identify the version? Currently we are at v11.0.0 but previous versions use a two-digit version name (v10.0).
  • Opening suggestion: we either use a two-digit version, or some kind of date-based system.
• Iteration: What will we iterate?
  • Opening suggestion: usually second digit unless a major overhaul (e.g. move to a new system), or just the date of the release.

Specifically seeking input from: @JacobCarley-NOAA @aerorahul @DavidHuber-NOAA @AlexanderRichert-NOAA

[aerorahul]

@JamesPolly-NCO Thanks for opening an issue to capture the spirit of updating standards as practices and tools evolve.

A few comments that come to mind as I read through the issue:

1. Cadence: Unlike software, standards aren't updated for "bugs", and more for clarity or newer functionality. Since these are operational standards, core principles for stability, logging, preventing software bloat, to name a few should be respected. Will there be a "trial" period for a change to be tested out before it becomes a fixture of a standard? I can imagine some new proposed idea may or may not pan out in the medium/long term. To prevent developer whiplash, what guardrails would be put in place?
2. Approval: creating a standards board or committee consisting of a few key people who can argue for and against an update. Anyone arguing for should be put to argue against as well.
3. Stable/Latest: Are new upgrades supposed to adhere to the latest or just follow the stable version? When will stable become latest and what overhead does that put on unsuspecting application developers who fall far from the latest tag?

Again, thank you for creating this issue, and IMO, there is a lot of room for discussion. I look forward to hearing others thoughts on this topic.

[AlexanderRichert-NOAA]

My questions pretty much boil down to Rahul's 1st & 3rd points-- I think some clarification about how the tags will be used would be helpful, especially in terms of their implications for developers/deliveries, as well as for instance whether there's a world where tags/branches are reviewed/explored/tested in some way but without necessarily ultimately being adopted.

[JacobCarley-NOAA]

I concur with the points noted by @AlexanderRichert-NOAA and @aerorahul

Do we want to have a Release Candidate phase for comment?

As for versioning and iteration naming: would Semantic Versioning, or some flavor of it, apply here?

I really want to emphasize @aerorahul 's point here:

Stable/Latest: Are new upgrades supposed to adhere to the latest or just follow the stable version? When will stable become latest and what overhead does that put on unsuspecting application developers who fall far from the latest tag?

Say we've a team working on an implementation for a couple years based v11 standards. As they're nearing wrap up, maybe 2-3 months out, v12 of the standards comes out. Do they need to update their whole package before implementation? There are a probably a number of iterations on this scenario that would present a complex situation for ops and dev. I think we need to workshop some ideas about how fold in new standards into the packages in a sustainable way.

[StevenEarle-NCO]

One possibility... Two digit version standard for the standards. If it's a minor update then a developer would be expected to adhere to the standard no matter where they are at in their development cycle. By definition, a minor update would not lead to a big change for a developer. If it's a major version update then we talk about it... there are some cases where it would be worth the effort to adhere to the latest and others where it makes sense to implement based on the previous version of the standards. Cadence - I hope at some point we get to a point where they just happen, but forcing a cadence right now is a good thing. I don't think a standard should be a standard until it goes through some level of a trial. Obviously the amount of time will vary depending on the scale of the change being proposed. In other words, "stable" standards are vetted through issues and only get into a version after that. Boards and committees make me cringe but I'm not opposed if we do it in a small / efficient way Steven

…

On Wed, Jun 10, 2026 at 1:31 PM JacobCarley-NOAA ***@***.***> wrote: *JacobCarley-NOAA* left a comment (NCO-HPC/nws-hpc-standards#34) <#34 (comment)> I concur with the points noted by @AlexanderRichert-NOAA <https://github.com/AlexanderRichert-NOAA> and @aerorahul <https://github.com/aerorahul> Do we want to have a Release Candidate phase for comment? As for versioning and iteration naming: would Semantic Versioning <https://semver.org/>, or some flavor of it, apply here? I really want to emphasize @aerorahul <https://github.com/aerorahul> 's point here: Stable/Latest: Are new upgrades supposed to adhere to the latest or just follow the stable version? When will stable become latest and what overhead does that put on unsuspecting application developers who fall far from the latest tag? Say we've a team working on an implementation for a couple years based v11 standards. As they're nearing wrap up, maybe 2-3 months out, v12 of the standards comes out. Do they need to update their whole package before implementation? There are a probably a number of iterations on this scenario that would present a complex situation for ops and dev. I think we need to workshop some ideas about how fold in new standards into the packages in a sustainable way. — Reply to this email directly, view it on GitHub <#34?email_source=notifications&email_token=AC37LPILEIXZLTGRBC53WNL47GLM5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRXGI3TCNBZGYZKM4TFMFZW63VGMFZXG2LHN2SWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4672714962>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC37LPL4JYX4DRVZ5HKH2O347GLM5AVCNFSNUABFKJSXA33TNF2G64TZHM4TONJXGQZTQOBRHNEXG43VMU5TINRSGQ4DAOBUG4Y2C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AC37LPKZLPJACAZV4GHQHQL47GLM5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRXGI3TCNBZGYZKM4TFMFZW63VGMFZXG2LHN2SWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AC37LPPCYGOCS2IIDIHGCET47GLM5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRXGI3TCNBZGYZKM4TFMFZW63VGMFZXG2LHN2SWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you were assigned.Message ID: ***@***.***>

[JamesPolly-NCO]

Really appreciate the feedback here. I want to continue to focus on the topic that has received the most attention.

I think some clarification about how the tags will be used would be helpful, especially in terms of their implications for developers/deliveries

Will there be a "trial" period for a change to be tested [and thus preventing] developer whiplash?

As [a dev team is] nearing wrap up, maybe 2-3 months out, v12 of the standards comes out. Do they need to update their whole package before implementation?

These concerns are great, and definitely what I hope to be discussing here. Thanks to @aerorahul, @AlexanderRichert-NOAA, and @JacobCarley-NOAA.

I propose we agree on some process and commit this agreement to the standards moving forward. As for the process, let's work on shaping the following bullets so that we can agree on each one:

• At the T2O kickoff meeting, we agree to the version of the standards that the project will be held accountable to. In general, this should be the most recent "stable" release, which will correspond to a version number that will always be available via the docs homepage.
• We will continue to incorporate PRs to the standards as they are submitted.
• For each PR, we review and approve the changes, agreeing on minor/major scope.
• These PRs will immediately be present in the "latest" release of the standards.
• If these PRs contain a major change, then the next scheduled release will have the first digit of the semantic version number iterated. Otherwise, the second digit of the version number will be iterated at the next scheduled release.
• Every three months, we will cut a new version number on the document, determined by the above bullet, and the "stable" release will be the same as the "latest" release at that time.
• When a project is being finalized during T2O, and during the NCO review process, the "latest" release may still serve as an optimal goal where appropriate and possible.

As with everything in the standards document, if we find that it doesn't work out, we can make a PR to remove it.

In general, the release cadence is the maximum time period in which your desired changes will be in the flux state ("latest") and not be the default "stable" T2O configuration.

We will need to make some changes and correct them as we go.

[JamesPolly-NCO]

Reducing scope of what I try to get consensus and agreement on. Can we agree on the following process:

• At the T2O kickoff meeting, we agree to the version of the standards that the project will be held accountable to. In general, this should be the most recent "stable" release, which will correspond to a version number that will always be available via the docs homepage.
• We will continue to incorporate PRs to the standards as they are submitted, discussed, and approved.
• For each PR, we review and approve the changes will be categorized as either minor or major.
• These PRs will immediately be present in the "latest" release of the standards.

Let's try to get this far and then we'll worry about release cadence, and "latest" vs. "stable."