semantic-release

[PhearZero]

ℹ️ Overview

⚠️ Once this PR is merged into dev, it will publish the first v1.0.0-beta.1 release ⚠️

Adds semantic-release with conventional commits .

• uses main for full release
• uses dev for pre-release

📝 TODO Items:

• Switch to npm, using npm.pkg.github.com for testing
• Write CONTRIBUTING.md guide outlining the workflow

Demo:

• Releases
• Packages

Workflow

1. feature|fix|chore branches are created from dev
2. feature|fix|chore are merged back into dev (v1.0.0.beta.1 - release.yml)
3. When dev is ready for a full release, it is merged into main (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"
   

Loading

[netlify]

✅ Deploy Preview for tealscript ready!

Name	Link
🔨 Latest commit	d7d4e8c
🔍 Latest deploy log	https://app.netlify.com/sites/tealscript/deploys/6518f0f58e61b200082643da
😎 Deploy Preview	https://deploy-preview-101--tealscript.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[joe-p]

Do we need to go to v1.0.0-beta.1? I would prefer to stick with 0.x versioning because I think it's more explicitly advertises instability and it would allow the stable release to be 1.0.0 which would be nice.

[PhearZero]

Do we need to go to v1.0.0-beta.1? I would prefer to stick with 0.x versioning because I think it's more explicitly advertises instability and it would allow the stable release to be 1.0.0 which would be nice.

Yea, I like the 0.X.X as well and agree with it's semantics. semantic-release has a strong opinion that it must start with 1.0.0.

We can leave this as a draft and adopt the release cycle when it's closer to 1.0.0. Then use whatever features are in develop as the 1.0.0-beta.X to catch any last minute hotfixes.

I'll add you to my fork and feel free to mess around with the workflow

[joe-p]

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 semantic-release

[PhearZero]

I think that is why other release managers are getting some adoption, semantic-release is very opinionated on specific things like version numbers. Their solution is prereleases which is the X.beta.X packages.

https://semantic-release.gitbook.io/semantic-release/support/faq#can-i-set-the-initial-release-version-of-my-package-to-0.0.1

[joe-p]

Would it be possible to increment the patch/feat version with beta tag instead of incrementing the beta number.

For example, instead of 1.0.0.beta.1 -> 1.0.0.beta.2 it would be 1.0.0.beta -> 1.1.0.beta

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.

[PhearZero]

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