This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-28
Channels
- # adventofcode (4)
- # announcements (1)
- # babashka (4)
- # beginners (23)
- # calva (15)
- # cider (8)
- # clj-kondo (30)
- # cljsrn (1)
- # clojure (29)
- # clojure-europe (15)
- # clojure-uk (2)
- # clojurescript (10)
- # community-development (4)
- # cryogen (3)
- # cursive (4)
- # emacs (3)
- # figwheel-main (2)
- # fulcro (13)
- # jobs-discuss (1)
- # kaocha (1)
- # luminus (1)
- # meander (2)
- # off-topic (78)
- # pathom (2)
- # reagent (13)
- # rewrite-clj (56)
- # ring-swagger (2)
- # tools-deps (15)
- # vim (3)
I propose the following:
• PRs should not change the version in project.clj.
• A CHANGELOG file should be updated by each PR.
• The "normal" state of the repo should have a version of x.y.z-SNAPSHOT. Thus noting that the current version of the repo is in between releases.
• Before a release, the CHANGELOG file and any documentation (especially the README) should be updated to the new release version.
• When a release is made, we can run lein release to update the version in project.clj, make a commit, tag the release, and create a new version ending in -SNAPSHOT.
Thoughts? (Preferably in a thread).
I like the CHANGELOG here https://github.com/oauth2-proxy/oauth2-proxy/blob/master/CHANGELOG.md If you look at the PR template https://github.com/oauth2-proxy/oauth2-proxy/blob/master/.github/PULL_REQUEST_TEMPLATE.md you see it does not always require changes to the changelog which makes sense for tiny ones? We should also write something similar to https://github.com/oauth2-proxy/oauth2-proxy/blob/master/CONTRIBUTING.md and https://github.com/oauth2-proxy/oauth2-proxy/blob/master/RELEASE.md I think.
Thanks for the feedback. I looked at the CHANGELOG you pointed at. I like the mention of each PR. I like the section for breaking changes. I like the idea of a summary. I would also add dates and some sections (Deprecated, Fixed, Security) as per http://keepachangelog.com . Thanks for the links to the CONTRIBUTING and RELEASE files. Yeah, something like those would be good.