Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

## [Unreleased]

## [1.1.0] - 2026-06-12
## [3.2.0] - 2026-06-17

- Add support for QGIS 4.x (Qt6-based) releases, while remaining
compatible with QGIS 3.22 and later
Expand Down
49 changes: 49 additions & 0 deletions RELEASING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# Releasing

This document describes how a new version of the **Add to Felt** plugin is
released.

## Versioning

The **git tag is the source of truth for the version.** When a release is
published, the [`release.yml`](.github/workflows/release.yml) workflow runs
`qgis-plugin-ci release <tag>`, which stamps the tag name into the packaged
`felt/metadata.txt` `version=` field — overriding whatever value is committed
there.

- Tags use **no `v` prefix** (e.g. `3.2.0`, not `v3.2.0`). The tag name becomes
the version string verbatim, so a `v` prefix would ship a version literally
named `v3.2.0`.
- The `version=` field in `felt/metadata.txt` and the entries in
`CHANGELOG.md` are cosmetic — they do not drive the release and are not
prominently surfaced to users. Keep them consistent for hygiene, but the tag
is what matters.

## Steps

1. **(Optional) Update the changelog and metadata on a branch.** Move items out
of `[Unreleased]` in `CHANGELOG.md` into a new `## [<version>] - <date>`
section, and bump `version=` in `felt/metadata.txt` to match. Open a PR and
merge to `main`. This is cosmetic hygiene, not required for the release to
succeed.

2. **Create a GitHub Release** with a new tag (e.g. `3.2.0`), targeting `main`.
Publishing the release triggers [`release.yml`](.github/workflows/release.yml),
which builds `felt.<version>.zip`, stamps `version=<tag>` into its
`metadata.txt`, and attaches the zip to the GitHub release.

3. **Manually upload the zip to plugins.qgis.org.** Nothing in this repo
publishes to the QGIS plugin repository — the workflow only attaches the zip
to the GitHub release. Download `felt.<version>.zip` from the release and
upload it at <https://plugins.qgis.org/plugins/felt/> (logged in with an
account that has rights on the plugin). This is what makes the new version
available to users in QGIS' Plugin Manager.

## Notes

- `release.yml` passes only `--github-token`, so it does **not** publish to
plugins.qgis.org; that step is manual (see step 3).
- On every push and pull request, [`build.yml`](.github/workflows/build.yml)
builds an `-alpha` package via `qgis-plugin-ci package` and uploads it as a CI
artifact (with a download link posted on the PR). This is for testing
pre-release builds and is not part of the release path.
4 changes: 2 additions & 2 deletions felt/metadata.txt
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ name=Add to Felt
qgisMinimumVersion=3.22
qgisMaximumVersion=4.99
description=Create a collaborative Felt (felt.com) map from QGIS
version=1.1.0
version=3.2.0
author=Felt
email=support@felt.com

Expand All @@ -25,7 +25,7 @@ repository=https://github.com/felt/qgis-plugin
# Recommended items:

# Uncomment the following line and add your changelog:
changelog=changelog
changelog=

# Tags are comma separated with spaces allowed
tags=shared,collaboration,sharing,maps,publishing,public,comments,data,layers,realtime,cloud,media,browser,online,publication,webmapping,internet,webgis,capture,catalog
Expand Down
Loading