@@ -0,0 +1,92 @@
1+# Maintainers' Guide
2+
3+## Release Checklist
4+
5+* Check if any critical pending bugs or issues are to be included
6+* _Documentation_:
7+
8+ * Update the README if needed.
9+ * Make sure haddock docs are consistent with the changes in the release
10+
11+* _Benchmarks_:
12+
13+ * Check regressions from previous release
14+ * Check comparative benchmarks using streaming-benchmarks
15+
16+* _Update changelog_:
17+
18+ * Change the `Unreleased` section at the top of changelog file to the new
19+ release version number and make an `Unreleased` section above it. Using
20+ `Unreleased` instead of the next release number for unreleased changes is
21+ important. If we use the next release number instead, then when adding a
22+ new change to the changelog, at one look we cannot know whether the
23+ release number on top is unreleased or released.
24+
25+ * Make sure all the bug fixes being included in this release are marked
26+ with a target release on github. So that users can search by release if
27+ they want.
28+
29+* _Update Package Metadata:_
30+
31+ * Update `stack.yaml` to latest stable resolver, cleanup extra-deps
32+ * Make sure the description in cabal file is in sync with README and other docs
33+ * Make sure CI configs include last three major releases of GHC in CI testing.
34+ * Update `tested-with` field
35+ * Make sure all dependency bounds are correct
36+ * Bump the package version
37+
38+* _Upload_:
39+
40+ * Wait for final CI tests to pass:
41+
42+ * Create a git tag corresponding to the release where X.Y.Z is the new
43+ package version (`git tag vX.Y.Z && git push -f origin v.X.Y.Z`).
44+ * Mask out the build status lines from the README
45+ * Upload to hackage (`stack upload .`)
46+ * Add to stackage (`build-constraints.yaml` in Stackage repo) if needed
47+ * Optionally upload `package-X.Y.Z-sdist.tar.gz` to github release page
48+ * Update release contributors on github release page
49+ (`git shortlog -s prev_tag..new_tag | sed $'s/^[0-9 \t]*/* /' | sort -f`)
50+ * Update and if needed release streaming-benchmarks package
51+ * Check https://matrix.hackage.haskell.org/package/streamly
52+ * Check haddocks on Hackage, upload if not built
53+ * Announce to haskell-cafe@haskell.org
54+
55+## Managing Changes
56+
57+### User Impacting Changes
58+
59+__RULE__ Any commit that may affect the end user in some way MUST have either a
60+changelog entry OR MUST have an issue marked with one of the following labels
61+OR both. We can have more than one of these labels on the same issue e.g.
62+breaking, enhancement:
63+
64+* breaking
65+* deprecating
66+* enhancement
67+* bug
68+
69+Note that if you are making a big feature change you may have a single issue
70+for that feature and attach many commits with it. So you do not necessarily
71+need to have an issue for each commit.
72+
73+Every new issue that requires a fix MAY be marked with a target release. But
74+remember that before we make a new release EVERY issue with a commit included
75+in that release that affects the end user MUST have the target release
76+correctly set.
77+
78+### Maintenance Changes
79+
80+Commits that do not impact the end user in any way are not required to have a
81+changelog entry or an issue. Issues that do not have a corresponding commit
82+may be left without a label but preferably should be marked with one of the
83+following:
84+
85+* invalid
86+* question
87+* wontfix
88+* maintenance
89+
90+## TODO
91+
92+* GPG signed releases and tags