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. |
| Alpha | 1.5.0-alpha |
A preview of the next release. Note there is no
numeric counter on the suffix — it is simply
-alpha. 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
Alpha builds are published from the alpha branch using a
-alpha pre-release version. When an alpha is deemed
ready, its code is merged into the stable branch and
tagged with a direct, final version (dropping the suffix), which is
then published as the new stable release.
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
| Branch | Purpose | Publishes |
|---|---|---|
stable | Production-ready code. | Final versions, e.g. 1.4.0. |
alpha | Active development of the next release. | Pre-releases, e.g. 1.5.0-alpha. |
Contributions are raised against the alpha 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
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-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.