Release process appears out of sync: newer versions on main not tagged or published as GitHub Releases

[loren-osborn]

Description

It appears that the Universal repository’s release signaling may be out of sync with ongoing development, which makes it difficult for downstream users to identify stable or intended release versions.

Specifically:

• The GitHub Releases page currently lists v3.80 as the latest release.
• The repository history and commit messages indicate subsequent versions (e.g. 3.81 → 3.90) being incremented on main.
• CMake configuration reports newer versions at configure time (e.g. PROJECT_VERSION = 3.88.x / 3.90.x depending on commit).
• git describe --tags produces values like v3.81-53-g<hash>, suggesting tags exist but are not aligned with published releases.
• There does not appear to be a tagged v3.82 (or later) release, nor a corresponding GitHub Release entry.

As a result, users cannot reliably answer:

• “What is the current released version of Universal?”
• “Is main considered stable?”
• “Which commit corresponds to version 3.9x?”

⸻

Steps / Evidence

Examples observed locally:

% git describe --tags --always                                        
v3.81-25-g2d331fc1

% cmake -S ../../third_party/universal -B build 2>&1 | grep -i version
-- PROJECT_VERSION             = 3.90.1.ca7a2ad1
--   Version                          :   3.90.1.ca7a2ad1
--   UNIVERSAL_BUILD_NUMBER_CONVERSIONS         :   OFF

GitHub UI:

• Releases page shows v3.80 as latest.
• main branch contains commits labeled “V3.90”.

⸻

Why this matters

For downstream consumers and integrators:

• It’s unclear which commit is intended to be a stable release
• Pinning dependencies by tag vs. branch produces different behavior
• Test failures on main are difficult to interpret without knowing whether the branch is expected to be green

Even a short note clarifying the intended release workflow would help significantly.

⸻

Suggested resolutions (any one would help)

• Publish GitHub Releases for newer versions already reflected in commit history, or
• Add annotated version tags (e.g. v3.90) matching commit messages, or
• Document that main is the authoritative release branch and GitHub Releases are no longer maintained

⸻

Environment

• Platform: macOS 15.5 Sequoia
• Build system: CMake
• Source: GitHub repo stillwater-sc/universal

⸻

Closing

This may be intentional, but if so it would be helpful to document.
If not, this issue may help surface a release automation gap.

Thanks for maintaining Universal — it’s a valuable library.

[Ravenwater]

@loren-osborn yes, this workflow needs to be improved. Right now it is a manual process, and the past couple of dev branch merges have gone unreleased.

[Ravenwater]

We now have an automated development branch/merge/release workflow triggered by CI.

Tested it with v3.92, which also has now verified signing and a full-regression manual CI trigger workflow

[loren-osborn]

Very glad to hear!