"fpm new" could create a minimal CHANGELOG.md file in the project

[vmagnin]

When creating a new fpm project, fpm could create a minimal CHANGELOG.md file based for example on the Keep a Changelog format (MIT license). Even if the history of a project is recorded in the versioning system (git for example), it is a good practice to write the main changes in a changelog: the user is not interested by the atomic granularity in the commits history but wants to know what has significantly changed since the last version of the project.

That file would be in the same directory as the README.md, and it would be created in all the situations where the README.md is created.

If the community is interested by that feature, I could work on it. In that case it could become my first contribution to fpm and a good occasion to discover its code with an easy feature to implement.

[vmagnin]

I have forked fpm and detected with grep -nRI README the places where to introduce my new code:

• fpm/src/fpm/cmd/new.f90
• src/fpm_command_line.f90
• test/new_test/new_test.f90

The fpm test are OK, and fpm now creates a CHANGELOG.md alongside the README.md. And fpm new --help is printing information about the creation of the file.

I have pushed the two commits to my fork:
vmagnin@c4a3138
vmagnin@64a40e1
The second commit just add a link toward Semantic Versioning, as advised by Keep a Changelog.

Let me know if you think this is an (interesting.and.acceptable) first contribution to fpm.

[ivan-pi]

I think it is an interesting idea, but since it would essentially force this practice upon all new fpm projects I think we need the consensus from a few more people. cc @LKedward @urbanjost @milancurcic @certik

My current feeling is that most calls to fpm new will be one off "experiments" or quick projects together thrown together to test something, and only a fraction of these will mature into published packages.

If implemented in the default behavior, I would also add an option fpm new --no-changelog to be able to suppress it (although most likely I will end up using rm CHANGELOG.md since I don't have to remember anything).

[awvwgk]

I'm not opposed to this idea and we might want to start keeping a changelog for fpm as well, a ChangeLog.md is there but still empty.

[certik]

I struggle with changelogs in all my projects. Lately I simply manually go over merged merge/pull requests and create one by hand for the Fortran's newsletter. I think maintaining a changelog is probably out of scope for fpm. Regarding creating one, I am not sure it should be done by default but let's at least put the functionality under an optional flag. Changing the flag to be default is a simple change we can always do later.

[urbanjost]

A changelog utility is something I consider more as a plugin utility.

For example, in my group we have a very specific changelog-like utility ("tracker") where you supply a category (DIF, ADD, PROPOSAL, VALIDATION, PROPOSAL, PLANNED FEATURE, REFERENCES, APPROVAL, ...) and a DISTRO used for automatic notifications, and OWNER and a QA file when appropriate. We would be required to continue to use that process even if a changelog function was added to fpm(1) unless it provided similar functionality.

So I like the concept of having a record that tracks more than just a commit history but I agree with the above comments about it being required primarily for large projects; and suspect larger projects will have a required tracking method already.

So if it can be implemented as a separate program and does not use the core project description automatically (I can picture changelogs that could) or other parts of the existing/envisioned core then it should be considered whether it should be implemented as an independent utility.

Since those ideas are not necessarily exclusive and it would encourage good practice out of the gate I think that it should be added but only create a file if --full is used or it is explicitly specified, similiar to the example/ directory.

What format (flat text, markdown, XML, HTML, ...) is proposed? So far fpm(1) itself has primarily been using github and git for proposals, bug tracking, presenting documentation. Howdo you envision fpm(1) development changing as a result of having a changelog functionality?

[vmagnin]

What format (flat text, markdown, XML, HTML, ...) is proposed?

The format I proposed is markdown, and the CHANGELOG.md file would contain an empty template based on https://keepachangelog.com/en/1.0.0/ format.

So far fpm(1) itself has primarily been using github and git for proposals, bug tracking, presenting documentation. How do you envision fpm(1) development changing as a result of having a changelog functionality?

Note that the goal of my proposition was not to modify the way the fpm changelog itself is made, on the https://github.com/fortran-lang/fpm/releases page. But it was oriented toward the user who wants to create and publish Fortran projects with fpm.

Personally, I prefer the CHANGELOG.md file method because it is always easily visible alongside the README.md in the root directory of the project. If someone just git clone the current code of a project, he will not see the changelog on the release page. On the developer side, when I am ready to commit a new feature that could interest the user, I add it in the CHANGELOG.md file before committing.

[urbanjost]

Sounds better the more I hear. Thanks for the elaboration.