Unform: Use existing patterns to commits, versioning and changelog

[cleitonper]

Description of issue

Currently we are using our own commiting rules. Instead of it, would be interesting make use of a popular pattern like conventional commits. It's based on the the Angular convention and quite similar to the pattern we are using.

In addition, making use of this pattern we can enable cool features like automatic versioning and changelog management with the standart-version tool. This tool uses the Semantic Versioning pattern that's make the versions of this library more consistent with the made changes.

Usage example

feat(form): a new cool feature

BRAKING CHANGE: introducing a breaking change

Fix the issue #123

This commit will trigger a MAJOR update acording with Semantic Versioning rules.

---

Read more at Semantic Versioning.

[pellizzetti]

Our commitlint rules was tailored taking into account our needs and to be reused across every lib that we publish. Since commitlint rules are so simple and easy to set up I fail to see the point in switching. 😄

I had even read the linked conventional commits page and specs already, the one thing that caught my eye was:

A description MUST be provided after the BREAKING CHANGE:, describing what has changed about the API, e.g., BREAKING CHANGE: environment variables now take precedence over config files.

Do you have any experience with this convention? I'm curious to know how they enforce that (if they do enforce).

---

Now, automatic versioning and changelog management are two very interesting subject (that we are already thinking into setting up) but those can be instated using any convention/rules, no?

[cleitonper]

Do you have any experience with this convention?

No, i don't, but i think that's god for a open source project make use of a popular commit convention mainly because this convention is already known by many developers. it provides less of an entrance barrier for potential contributors.

---

I'm curious to know how they enforce that (convention)

To enforce the conventional commits rules we can use of the a sharable commitlint config: @commitlint/config-conventional.

---

one thing that caught my eye was:

A description MUST be provided after the BREAKING CHANGE:, describing what has changed about the API, e.g., BREAKING CHANGE: environment variables now take precedence over config files.

Me too. Other interesting thing is the use of the ! symbol to call attention to a breaking change commit:

feat!: Add new prop multiline to input

BREAKING CHANGE: the Texarea component was removed

---

Now, automatic versioning and changelog management are two very interesting subject (that we are already thinking into setting up) but those can be instated using any convention/rules, no?

They use conventional commits rules by default, but yes, we can use any convention/rules.

---

The point is: these proposed changes can make unform more attractive for developers that already knows the mentioned patterns because they dont't need to read more one convention/rule/pattern.

[pellizzetti]

No, i don't, but i think that's god for a open source project make use of a popular commit convention mainly because this convention is already known by many developers. it provides less of an entrance barrier for potential contributors.

Thing is, both are pretty similar, the main differences are that ours is more strict (no warnings) and types.

To enforce the conventional commits rules we can use of the a sharable commitlint config: @commitlint/config-conventional.

Before commenting here and when I was creating our rules I went to check the rules that you linked, there's no mention of breaking changes so I'm gonna assume that they just don't truly enforce it.

---

As I said, I don't see any point in changing it.

But, we would love to receive PR regarding:

• Specifying break change in contribution guide;
• Automatic versioning;
• Automatic changelog generation.

❤️

[diego3g]

@cleitonper @pellizzetti Guys, i'll close this issue for now as we are not having any new discussions, also, please feel free to reopen it if anything must still be discussed, and a PR with this implementation would be really appreciated.