@@ -0,0 +1,92 @@
5+* Check if any critical pending bugs or issues are to be included
8+ * Update the README if needed.
9+ * Make sure haddock docs are consistent with the changes in the release
13+ * Check regressions from previous release
14+ * Check comparative benchmarks using streaming-benchmarks
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.
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
29+* _Update Package Metadata:_
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
40+ * Wait for final CI tests to pass:
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
57+### User Impacting Changes
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:
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.
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
78+### Maintenance Changes
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
92+* GPG signed releases and tags