Changelog of a sort - to follow easily what was added and when

[uded]

Currently I am an observer on Github, but this is a very inconvenient way to follow what is new on this awesome list. It would be great if there could be a changelog with dates or some other form available to see newly added libraries, projects, etc.

Maybe using semantic commits for that? Then the changelog can be actually easily generated...

[avelino]

I agree that this feature would be great, but we need to think about how to generate this changelog automatically.

It can be done by looking at the commit history and taking the diff to know what was changed, since this software is done, we can configure a cronjob (via GitHub action) to run once a week and generate a new structured markdown file and generate an html page for the site.

What do you think about this architecture above, makes sense? @uded could you contribute with this implementation?

Here's an example and job implementation that we run weekly, write by @mrKappen:

• Investigate if the package (repository) has not had a commit in over a year #3211
• source: https://github.com/avelino/awesome-go/blob/master/test_stale_repositories.go
• job: https://github.com/avelino/awesome-go/blob/master/.github/workflows/run-check.yaml

[uded]

It's doable as long as there is a format of the commit message which we can follow. Hence my suggestion would be to use something like semantic commits, which can structurize the message. I.e.:

added(databases): https://github.com/project/path
deleted(network): https://github.com/project/path

I am open to suggestions here on what would be the best format, but if we can enforce that the rest is easy to do using existing tools or slightly modifying them.

[avelino]

ensure standard in commit would say it is impossible, many people do not follow the pull request template, I do not believe they will follow pattern to commit

we need to create an "intelligence" that identifies this in the received patch (git commit), example:
d021e7a?branch=d021e7af7d03718da37d53a54eabc95919d827cf&diff=unified#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5

[mrKappen]

you could perhaps use the heading to determine which category the added item would fit in and use that to create the changelog. That way you wouldn't have to rely on users following a particular format. This would also be backwards compatible and you could create the change log from the very beginning of this repo. Granted, this isn't a perfect solution, but it might be a decent enough way forward

[uded]

@avelino I think we can enforce some standards - using hooks. Sorry, if you want a standardization then just follow it or go away, simple as that. So instead of trying to work around people who do not care, maybe we shouldn't care instead. Simple as it is to implement a mechanism to create a changelog with a proper commit message, trying to figure out how to go around a problem of freely formatted messages will always create issues down the road...

There are ready to be used solutions for Github:

• https://github.com/SystangoTechnologies/commit-message-lint
• https://github.com/marketplace/commitcheck
• https://github.com/marketplace/actions/commit-linter

and many more...

---

Also, I would think that creating a history changelog makes no sense right now. Just cut a fine line and say from now we gonna make it. Otherwise, the effort required to figure out how to make a changelog for all past commits is high. And, IMHO, time wasted. Since it was not there before just accept it. It is what it is...

[uded]

After some investigations what I can see is a couple of options.

1. Conventional (well, sort of) commits + custom scripts
   This is a rather simple solution in which AwesomeGo will have that enforce a format of each commit message to follow strict rules. We can use one of the GithubApps for that, as listed above. The format that I would be suggesting was also mentioned above: [added|removed]({{category}}): {{name of the library}} - {{description}}. Theoretically, this will allow us to create a nice, category based changelog updated on every commit.
2. Somewhat conventional commit with GithubApps
   Since we really do not need much my suggestion would be to minimize the effort, scripting (which sooner or later will break or will require adjusting), etc. we can use two Github apps - one to enforce the format of the PR message according to our rules (most of the above will do), and the second one to create changelogs automatically. Using this combo we minimize any impact on the repository, current workflow, etc. As far as I can tell looking over the last 30-50 commits - shouldn't be so difficult to change as most of the PR are starting with Add xxx anyway...
3. Custom scripting
   This is tricky. We can use some scripts to parse each commit content of the README.MD file and create a changelog. It will work but will require a substantial amount of effort to make it right. Theoretically, we have everything there, but it's not given and not ready to be used by any of the external tools known to me.

[uded]

BTW, is there a way to vote here? Would be nice :-)

[avelino]

I don't like to impose a pattern of how to describe a contribution (pull request), since we have some minimal requests for contributions and few follow - just look at the amount of PR that stays open for days

like option 3: create script looking for readme
we can use diff from the readme file with a period of 1 week, so we get what was removed, modified and added.

What do you think about it?