1- # Release Process
21
3- This document describes the steps needed to make a release:
42
5- ## ** On the main branch: **
3+ # Release Process
64
7- 1 . Update the top-level ` CHANGELOG.md ` with the commits/PRs since the previous
8- release (the changelogs for the other two packages link there). Ideally at
9- least PRs with breaking changes should already have modified the changelog to
10- list their breaking change.
5+ This document describes the steps needed to make a release.
6+ All packages are versioned and released together.
117
12- 2 . Update the library version in ` pubspec.yaml ` for each supported library:
13- - ` maplibre_gl_platform_interface `
14- - ` maplibre_gl_web `
15- - ` flutter-maplibre-gl `
8+ ## Preparing a release
169
17- ### Version numbering
10+ ### Define the release version number
1811
1912As long as we are on major version 0 (i.e. version number 0.xx.xx), we increase
2013the minor component (e.g. from 0.16.0 to 0.17.0) for every breaking/significant
@@ -23,52 +16,28 @@ release.
2316We may want to make releases where we only increase the patch version (the final
2417digits) for small bug-fix-releases or similar.
2518
26- ## Only on the GitHub release branch
27-
28- 1 . After performing the above changes on the main branch (new changelog and
29- versions), create a new git release branch from the main branch, named
30- like ` git-release-x.y.z ` .
31-
32- 2 . On that branch:
33-
34- a. In ` flutter-maplibre-gl ` and ` maplibre_gl_web ` in their respective
35- pubspec.yaml file, change the ` ref ` value for the maplibre git dependencies
36- from ` main ` to ` git-release-x.y.z ` (the new git release branch).
37-
38- b. In the example app's pubspec.yaml: change the git refs
39- for ` maplibre_gl_platform_interface ` and ` maplibre_gl_platform_interface ` to
40- the new git release branch and comment out the ` dependency_overrides ` . Then
41- the example app will use the packages from this git release branch, instead
42- of their local copies. This way, inter-package dependencies can be tested and
43- users can see how to correctly use the release in their app.
44-
45- 4 . Then, create a GitHub release (` x.y.z ` ) with a new git tag (` x.y.z ` ) from
46- this git release branch (This can be done from the GitHub web interface).
47-
48- ## Only on the pub release branch
19+ ### Update the version number
4920
50- 1 . After performing the above changes on the git release branch, create a new
51- pub release branch from the git release branch, named
52- like ` pub-release-x.y.z ` .
21+ Update the library version in ` pubspec.yaml ` for each library:
22+ - ` maplibre_gl_platform_interface `
23+ - ` maplibre_gl_web `
24+ - ` maplibre_gl ` (root directory)
5325
54- 2 . On that branch:
26+ Ensure that also the dependent sub-packages are updated to the new version.
5527
56- a. In ` flutter-maplibre-gl ` and ` maplibre_gl_web ` in their pubspec.yaml files
57- change the maplibre git dependencies to hosted dependencies (regular pub.dev
58- dependencies) with the same version number.
28+ ### Update the changelog
5929
60- b. In the example apps's pubspec.yaml file, change
61- the ` maplibre_gl_platform_interface ` and ` maplibre_gl_platform_interface `
62- dependencies to use the hosted versions from pub.dev as well.
30+ Update the ` maplibre_gl ` (root directory) ` CHANGELOG.md ` with the commits/PRs since the previous
31+ release (the changelogs for the other two packages link there). Ideally at
32+ least PRs with breaking changes should already have modified the changelog to
33+ list their breaking change.
6334
64- ### Publishing order to pub.dev
35+ ### Create a PR
6536
66- Then the 3 plugins can be published from this pub release branch in this order (
67- because of the inter-package dependencies):
37+ Commit all changes and create a PR targeting the main branch.
6838
69- 1 . ` maplibre_gl_platform_interface `
70- 2 . ` maplibre_gl_web `
71- 3 . ` flutter-maplibre-gl `
39+ ## Creating a release
7240
73- (For the first two, of course only publish the contents of the relevant
74- subfolder with the same name)
41+ After the release PR has been merged, the release can be created
42+ by creating & pushing a tag on the main branch in the format ` vVERSION ` ,
43+ for example ` v0.20.0 ` .
0 commit comments