Replies: 6 comments 5 replies
-
|
Totally agree. We could start with the central libs (buchu, gotu e suma) that are more mature. |
Beta Was this translation helpful? Give feedback.
-
|
I found this here, I believe it explains how we should follow: https://github.com/semantic-release/semantic-release
Given a version number MAJOR.MINOR.PATCH, increment the:
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. About the commit messages indicating wich type of version it is. Here is an example of the release type that will be done based on a commit messages:
Here is a good article, about this: https://itnext.io/automate-your-releases-versioning-and-release-notes-with-semantic-release-d5575b73d986 |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, just updating you guys on version control and I've made some advances, but I'd like to hear from you guys on that. I am using https://github.com/semantic-release/semantic-release as a tool for this feature and I would like to point out a few things. Strengths:
Negative points:
I'm waiting for your feedback |
Beta Was this translation helpful? Give feedback.
-
|
It's a nice approach, and the market standard. semantic-release is the way to go |
Beta Was this translation helpful? Give feedback.
-
|
Wow, what amount of info did you have @jhomarolo, great job.
anyway, I agree to adopt that solution |
Beta Was this translation helpful? Give feedback.
-
|
All the libraries now uses seemantic release and commitizen to :
It's important to say that now we must use this format for commit messages (https://semver.org/). To help with this task I've implemented the commitizen to all libraries, just follow those steps:
We also restarted the version of all libraries since we moved to herbsjs organization #14 🚀 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I believe that with the growth of the library, we need to implement better control of release notes and also control of versions released X.X.X (ex: when a version goes from 1.0.10 to 1.1.0 instead of 1.0.11)
There is a convention for that and I believe we could follow it: https://semver.org/
Motivators for release notes:
Some tutorials about it: https://docs.github.com/en/github/administering-a-repository/managing-releases-in-a-repository
Beta Was this translation helpful? Give feedback.
All reactions