Move changelog to github releases.

dereuromark commented 4 years ago

I would like to propose moving the changelog to GitHub https://github.com/milesj/decoda/releases

This way, they are more readable directly, and could also be modified post release if sth was missing. The current "shipped" way is not that flexible.

Using GitHub here is also free and the recommended way, and so far unused.

Also: I think we are now ready for the 6.13 milestone Unless there are some fixes you also want to ship along with it?

alquerci commented 4 years ago

Disclaimer: I will share you my point of view and you are totally free to take actions that fit better your context.

It is a good things to have on the git repository informations about new features, fixes and "how to upgrade".

For sure there is $ git log but this is not a good developer experience and a waste of time.

Use cases

Help dev to upgrade from one to another Decoda version with confidence.
- As dev, I need to know what are BC breaks and how to migrate.
Having information about new features

Propositions

Add a link on the readme of https://github.com/milesj/decoda/releases
There are some tools that can generate a changelog from git history. The main idea is to do something like that
```
git log --reverse --oneline --no-merges <since>..<until>
```

Brainstorming

To be simple to contribute (create a PR), having the obligation to upgrade the change log directly on the PR as (Definition Of Done of a PR), is maybe to much restrictive. But "force" to document the modification along of the modification itself, remove the responsibility to the "releaser" (e.g. the guy who release) to write the changelog (on a file or on tag comment). The decision to postpone the writing of the changelog IMHO add more stuff to "releaser" as it need to see all commits and write the related message.
GitHub releases are good when there are binary files attached to the release, for a PHP library it is a bit overkill. As the tag can contain a message and be force push.

milesj commented 4 years ago

On my other projects, I actually support both the CHANGELOG.md file and GitHub releases (example: https://github.com/milesj/boost/releases). I like this approach as GHR can be hard to navigate since you need to dig through multiple packages, where as the changelog you can just grok (and it's also part of the historical source).

It's all automated since I use conventional commits. Not sure if there's a PHP equivalent however.

dereuromark commented 4 years ago

A link to the GH releases page would still be my favorite tbh. But in the end whatever works :)

alquerci commented 4 years ago

Just an idea launched: Having a doc about "how to make a release", maybe a good idea, why not, in complementary of one about "how to contribute".

Does the first one tackle the problematic of this issue?

dereuromark commented 4 years ago

In that case it shouldnt just be a doc, but also automated somewhat

I maintain 40+ repos, and I can tell you, having this overhead is not worth for anyone usually, especially not the maintainers :) Easiest to just collect for release and add to GH notes. Done.

alquerci commented 4 years ago

Yes, as dev we end up to automate every things with scripts.

... the common dev journey.

Hum, so the first point of the brainstorming may help too.

milesj / decoda