Skip to content
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

semantic-release #101

Open
wants to merge 7 commits into
base: dev
Choose a base branch
from

Conversation

PhearZero
Copy link
Member

@PhearZero PhearZero commented Aug 17, 2023

ℹ️ 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:

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
Copy link

netlify bot commented Aug 17, 2023

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...

QR Code

Use your smartphone camera to open QR code link.

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

@PhearZero PhearZero changed the title Chore/application life cycle semantic-release Aug 17, 2023
@joe-p
Copy link
Contributor

joe-p commented Aug 29, 2023

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
Copy link
Member Author

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
Copy link
Contributor

joe-p commented Aug 29, 2023

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
Copy link
Member Author

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

@PhearZero PhearZero marked this pull request as ready for review October 2, 2023 13:47
@joe-p
Copy link
Contributor

joe-p commented Oct 4, 2023

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants