-
Notifications
You must be signed in to change notification settings - Fork 18
semantic-release #101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
semantic-release #101
Conversation
✅ Deploy Preview for tealscript ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
67c1bae to
979a9a0
Compare
|
Do we need to go to |
Yea, I like the We can leave this as a draft and adopt the release cycle when it's closer to I'll add you to my fork and feel free to mess around with the workflow |
|
Weird... I would think it should be supported since it's part of the semantic versioning spec. Perhaps it's worthwhile to attempt to get upstream support in |
|
I think that is why other release managers are getting some adoption, |
# Conflicts: # .github/workflows/release.yml # package.json # yarn.lock
|
Would it be possible to increment the patch/feat version with beta tag instead of incrementing the beta number. For example, instead of If so, do you have any opinions against doing this? My rationale is that I want to release 1.x signify that there won't be any breaking changes, but beta to signify it's not yet production ready. Or maybe I'm over thinking it and we should just release it with 1.0 with ample warnings about it's current state. |
|
Sadly it's pretty ridgid 😔, the prerelease is always pointing to the next release (🔖v1.0.0 in this case). It requires the v1.0.0 release 🚀 in order to have a v1.1.0.beta.1 ⚗️ prerelease with the next batch of changes. It's a big milestone for sure! It's also just the start of the party 🥳, the worst case scenario is a v2 built with the lessons learned in v1🕺. A really good option to help deal with transitions are "feature/future flags🚩". Add the feature but disable it by default, when the flags are removed then bump the feature|major points🎉. Technically you could ship a v2 inside of the v1 that way🤯. Remix was very successful with their v2 |
ℹ️ Overview
Adds
semantic-releasewith conventional commits .mainforfull releasedevforpre-release📝 TODO Items:
npm, usingnpm.pkg.github.202132.xyzfor testingCONTRIBUTING.mdguide outlining the workflowDemo:
Workflow
feature|fix|chorebranches are created fromdevfeature|fix|choreare merged back intodev(v1.0.0.beta.1 - release.yml)devis ready for afull release, it is merged intomain(v1.0.0 - release.yml)--- title: Git Flow --- gitGraph commit tag: "0.37.0" branch dev checkout dev branch "feat/add-foo-123" checkout "feat/add-foo-123" commit id: "feat(foo): ..." commit id: "doc(foo): ..." checkout dev branch "feat/add-bar-123" checkout dev branch "feat/add-baz-123" checkout dev merge "feat/add-foo-123" tag: "v1.0.0.beta.1" checkout feat/add-bar-123 commit id: "chore(baz): ..." commit id: "feat(baz): ..." checkout dev merge feat/add-bar-123 tag: "v1.0.0.beta.2" checkout main merge dev type: HIGHLIGHT tag: "v1.0.0" checkout dev merge main tag: "v1.0.0" checkout "feat/add-baz-123" commit id: "doc(bar): ..." checkout dev merge "feat/add-baz-123" tag: "v1.1.0-beta.1" checkout main merge dev type: HIGHLIGHT tag: "v1.1.0"