[Suggestion] Automatic Version Increment and CFF Self-maintenance about tui-journal HOT 3 CLOSED

Thanks for the helpful suggestion @kevinmatthes
Currently, I still prefer to manage the releases manually, since the app is changing rapidly and there are some features that related for each other (Like tags and filter, then filter and filter popup). That's why I think controlling the versioning manually could be better for the current development phase.

For that I have two suggestions:

1. We Add CFF release date synchronization without the auto-incrementing feature for version if that's possible.
2. We can implement both feature but we make their workflow starts manually if find this approach better to implement.

I'll be glade to hear your opinion about that

from tui-journal.

Thank you for your feedback! I noticed that my explanations about the version incrementing were too brief, so I would like to add some more detailed information on this, in the following. Apart from the version incrementing, I will prepare a suggestion for the CFF release date update which is independent from the version incrementing.

Rust uses the Semantic Versioning (SemVer) model according to which a version triple a.b.c represents the evolution of the software with a being the major version, b being the minor version, and c being the patch version. If a new release introduces fixes to bugs, it is a patch release which will only increment the c part. If a new release adds a new functionality to the project without changing the public calling interface except for the optional addition of new symbols, it is a minor release which will increment the b part and reset the c part to zero. If a new release changes the public calling interface by, e.g., adding a new parameter to a public function, removing a public struct, or turning a public enum into a private one, it is a major release which will increment the a part and reset both the b and c parts to zero.

Software projects usually contain their versions at least once somewhere in the code base. In case of multiple places, it can be forgotten rather easily to adjust all places appropriately such that different files would expose different version information. A solution to this problem is a version incrementing system like bump2version which allows for the specification of custom versioning rules such that on release, all version strings will be updated automatically -- there will be no forgetting, anymore. But bump2version is about to become discontinued, so I made a SemVer incrementing feature part of Aeruginous v2.2.0.

You can plug-in the version incrementing system anywhere into the release steps, including manual updates as well as GitHub Action workflows. I would like to suggest the latter option such that, on release, you assemble your CHANGELOG as usual but when calling the workflow from the Actions tab, you would also need to specify whether you are about to create a major, a minor, or a patch release by selecting this from a drop down in the branch selection blob. Then, any version incrementing software will update each file which contains a version string, Aeruginous updates the CFF release date, and Aeruginous will assemble your RONLOG with the correct version. All steps, united to one -- without any further manual edits required! We can also add a workflow to push a tag to main such that the release creation will be triggered.

from tui-journal.

Thanks for the detail explanations!

I think it would be very useful to include the version incrementing feature within the workflow that assembles the CHANGELOG, since this workflow will be called before each release.
Doing that would make creating a new release just a breeze with triggering the workflow with the wanted arguments, then creating a new tag which will launch the release workflow 💯

If you think that including the CFF release date in the same workflow would be better then you can include it there too 👍

from tui-journal.