A modern programming language that makes developers happier.

kotlinlang

I would like to switch the default branch on Github from `develop` to `release` . The reason - avoid users confusion by having Readme not aligned with latest stable release. For example, recently we had that skip interceptor feature and it was described in Readme visible to all users, while actually it wasn’t deployed in stable releases. Some users might find out library and that feature (for example) could be a killer feature for selection for them and after adding the dependency they would end up without described feature and being frustrated.

With `release` being the default branch we can avoid such issue. Yeah, contributors will have to update target branch manually, but it is as big problem as having invalid info visible.

Any objections?

I’m generally against having `release` as default branch for a variety of reason:

• We will probably start receiving a lot of PR from first time contribs that are opening them against `release` rather than `develop` . I’m also afraid people might fix bugs on `release` that are already solved since a while (that would be a big waste of time).
• It’s sort of deterrent for people interested in our library to see that the last commit was 2/3 months ago (or more, basically the last release) while in fact the repo is quite active.
• It would be cool if people that clones the repo will have to do little to no setup to have Chucker working. Having to switch branch is not ideal.
• I’m using cli/cli (the github cli) to create PRs. That creates PR automatically without having to pass through the web. IIRC that works only against the default branch.

On the other hand it makes sense to don’t have sort of “out of date” documentation in the README. It’s probably time to switch using a wiki or a static website like other bigger projects are doing. That would allow to decouple documentation from the development flow.

Side note: we used to have Github pages active for some time <https://github.com/ChuckerTeam/chucker/blob/develop/_config.yml>

In case with static website - we could try something that I shared some time ago here <https://twitter.com/Piwai/status/1224014483737075712|https://twitter.com/Piwai/status/1224014483737075712>