Console configuration CHANGELOG

[FranL27]

Which area of this project could be most improved?

Console

Description

Hi everyone!
@edocrippaofficial and I were discussing about implementing an useful feature in the console design and deploy sections.

The idea is to have a shared CHANGELOG file where all the developers working on a project can add their changes to the project. Since CHANGELOG editing will be done from an entry in the design section, the CHANGELOG file will be associated with the active branch/tag.

The main purpose behind this idea is to have a single point where collect all the changes done in the console environment (Edit services tags, Add CRUD collection, Add ACL to an endpoint, ecc..).

This file will follow the Keep a Changelog standard.

Also, in the deploy section you should be able to take a look at the latest changes made to the CHANGELOG file along with the latest commits.

Since this is a fresh idea, we would like to hear your feedback! 🚀

Here some prototypes of the idea:
Branch master without any edit done:

Branch feat/feature with some changes:

After merging feat/feature into master and tagged the console:

Deploy section:

[fredmaggiowski]

Hi, thank you for the interesting idea!

We used to have explicit commits to highlight relevant changes and so the commit history being the actual "changelog"; I understand that commit messages may not provide enough information, however as a user I'd prefer not to maintain my own changelog (that would force me to write the same info in two places) but have it auto-generated based on my commits (maybe written following conventional commits) 🤔

What do think about this considerations?

[theliuk]

Commit history must be very good to become a summary of the features/bug fixes and this is not always the case.

[edocrippaofficial]

Hi @fredmaggiowski, what you are saying is right from an ideal point of view, but from a practical one it is difficult.
When you are in a "development" phase the devs can commit multiple times a day, each with a small modification or rollback. You can't force everyone to write small dev commits in a strict format, and even if we consider this the case, the number of commit would be so high that you will loose the main point.

If I want to know what a branch/tag is doing in the deploy section I can look at:

• the tag description, but that contains usually the changes from the previous version only, not the entire story
• the last commits, but again a few commits are not enough for a exhaustive comprehension of the whole tag properties

Obviously this is not mandatory, but if the team and the TLs are committed to spend a little time to take care of the project this can result in a much better experience for the future devs and the clients themselves.

I'll report the introduction of keepachangelog

What is a changelog?
A changelog is a file which contains a curated, chronologically ordered list of notable changes for each version of a project.

Why keep a changelog?
To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.

Who needs a changelog?
People do. Whether consumers or developers, the end users of software are human beings who care about what's in the software. When the software changes, people want to know why and how.

[fredmaggiowski]

I understand your point, and agree that the development phase may be messy on the commit history.

As of now the closest thing you can use (as also yourself mentioned) is using tags and for each tag provide relevant changes provided by that tag. Development flow can still be messy but when you are ready with the solution you tag it and provide the "changelog" as description; combining the ordered tag list with their descriptions may compose your changelog. How do you see such a feature?

Anyhow I get the feedback and is something we will make treasure of, especially because we are currently working on moving away the Design section from Git (both on a technical standpoint and on a feature standpoint). Everything is still in early development but the idea is that we won't leverage git for configuration management anymore; in the future this could make it possible to avoid user having to provide a "commit message" as it could be done in the background autonomously (the first iteration will still require a saving message); in this long-run picture how do you see something like a changelog? Is it still relevant 🤔 I don't think so as, just to make an example, you wouldn't keep a changelog of a cloud-based google document. What's would you expect the Console to do?