Versioning, branching & licensing
The shared conventions behind openxml-office, tauri-remote-ui,xml_rs and future projects. Versioning and branching are consistent everywhere; licensingcan 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 stablerelease 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 thecurrent documentation describes and what you should use in production. Cut by a maintainer pushing avX.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 onrelease. 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 matchingvX.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 therelease branch. See thecontribution 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
LICENSEfile 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-licensemodel. 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 thefull AGPL-3.0 text.
- Commercial — sponsorware (MIT terms).Commercial use requiressponsorship, 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.