Experimenting with release-please #67
Closed
yamcodes
announced in
Announcements
Replies: 1 comment
-
I'm closing this discussion now - we have decided not to use versioning for this project anymore and stick to Git and our docsite for documenting changes. Since the roadmap/spec is crystal clear - implement all of the RealWorld spec - there is no need for any outstanding changelog. Also, these tools are better used for package and this project is an app. If we need versioning we should use API versioning or date based versioning e.g. GitHub API. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We are experiementing with support for Google's release-please GitHub Action.
It's a seamless way to manage versioning and releases. Provided we already abide by coventional commits, it's a no brainer to use a tool that provides clarity and ease of discussion behind software changes. Excalidraw Editor is an example of another open-source tool in production that uses a release mechanism.
I personally have past experience with semantic-release, and while it's powerful I find myself looking for something simpler, and less restrictive.
The problem that release-please solves here is providing the freedom to decide when to create a new version. With other tools, the "when" is either cumbersome (i.e. with a CLI) or nearly impossible to control.
For now, we're on version
0.x
, until we handle all the action items in the "Backend Specs" section of the RealWorld spec docs.Beta Was this translation helpful? Give feedback.
All reactions