Versioning, branching & licensing

The shared conventions behind openxml-office, tauri-remote-ui, xml_rs and future projects. Versioning and branching are consistent everywhere; licensing can vary per project and per version, so always check the one you're using.

Versioning strategy

Releases follow Semantic Versioning (MAJOR.MINOR.PATCH) with three lifecycle stages. A single minor line can exist in more than one stage at the same time — for example 1.4 can be the current stable release while 1.5-alpha previews what's next.

Stage	Version form	What it means
Stable	`1.4.0`	The present, supported release. This is what the current documentation describes and what you should use in production. Cut by a maintainer pushing a `vX.Y.Z` git tag once an alpha line is judged ready.
Alpha	`1.5.0-alpha.3`	A preview of the next release, auto-published from every successful merge to `release`. The counter increments per merge and resets when the core version changes. APIs may change without notice.
Deprecated	`0.x`, older majors	Older releases that are no longer maintained and receive no security or bug fixes. Migrate to the current stable release.

How an alpha becomes stable

Every merge into the release branch is automatically built, versioned as X.Y.Z-alpha.<n>, published to the alpha channel and tagged. There is no separate stable branch — alpha and stable are two publish channels off the same line of code.

When a maintainer judges the current alpha line ready, they confirm the stability release by pushing a plain vX.Y.Z git tag (no -alpha suffix) at the chosen commit on release. That tag triggers the stable publish stage and marks the GitHub release as latest. The tag itself is the stability confirmation; no merge or branch promotion is involved.

How this maps to the docs

The current page of each project's docs always describes the latest stable release.
When active alpha work exists, an alpha entry is added to the project's version selector so you can preview upcoming changes.
Deprecated versions remain available in the version selector for reference but are clearly marked.

Branching model

There is a single long-lived branch, release. Stable and alpha are publish channels — not branches — so the same commits flow to both without a separate promotion step.

Trigger	Version produced	Publishes
Pull request → `release`	`X.Y.Z-alpha.<n>.pr.<pr>.<build>`	Nothing for libraries; web projects deploy a throw-away preview channel for review.
Merge → `release`	`X.Y.Z-alpha.<n>`	Alpha channel (registries / alpha docs site). A matching `vX.Y.Z-alpha.<n>` git tag is created automatically.
Maintainer pushes `vX.Y.Z` tag	`X.Y.Z` (verbatim from the tag)	Stable channel and GitHub latest release. No extra tag is created — the pushed tag is the stability confirmation.

Contributions are raised as pull requests against the release branch. See the contribution guide for the workflow.

Licensing

Licensing is not one-size-fits-all. It can differ from project to project, and even between versions of the same project, as terms evolve over time. Always check the license that applies to the specific project and version you're using — don't assume.

Where to find the authoritative terms for what you're using:

The License page in that project's docs (each version has its own).
The LICENSE file in the project's repository for the tag/branch you depend on.
The license field on the package itself (crates.io, npm, NuGet, etc.) for the exact version.

The model most projects follow

Many — though not all — of my projects use a dual-license model. Treat this as a guide, not a guarantee; the per-version license is the source of truth.

Open source — AGPL-3.0. Free to use, study and modify. Derivative works (forks, integrations, SaaS) must also be released under AGPL-3.0. See the full AGPL-3.0 text.
Commercial — sponsorware (MIT terms). Commercial use requires sponsorship, which grants access to a private repository under a commercial-friendly (MIT-terms) license, plus priority support.

If a project uses the dual-license model

Individuals, students, hobbyists, open source → use under AGPL-3.0.
Businesses, organizations, contractors → sponsor to obtain commercial rights.

Some releases (for example older or differently-licensed lines) may ship under other terms entirely. When in doubt, the per-version License page and LICENSE file win. For commercial licensing questions, contact contact@draviavemal.com.