Development/development strategy

[simenandre]

We talked about changing how we develop and deploy, in short, these are the changes we talked about:

• master --> main (meant for stable releases)
• alpha --> develop (meant for development)

develop branch will have canary releases, meaning it will release a prerelease version with every merge that contains at least one commit message annotated according to Conventional Commit.

We have to remember to change the configuration of Semantic Release with this change, this file:

swedbank-pay-sdk-js/.releaserc.json

Lines 30 to 38 in fc5ab94

	"branches": [
	"+([0-9])?(.{+([0-9]),x}).x",
	"master",
	"next",
	{
	"name": "alpha",
	"prerelease": true
	}
	]

The next branch will be used in the future for next mayor releases.

cc: @asbjornu @NullableInt

[NullableInt]

👍 We could keep the next branch for release candidates, if this is something we want.

[asbjornu]

We can also use release/* branches for releases, as per standard Git Flow.

[simenandre]

I agree with you @asbjornu. Better to have a spec to reference than something special.

So we'll end up with something like this then? 👇

"branches": [ 
   "+([0-9])?(.{+([0-9]),x}).x", 
   "main", 
   "release/*", 
   { 
     "name": "develop", 
     "prerelease": true 
   } 
 ] 

Who wants to do it?

[asbjornu]

Having release/* being named develop looks very strange to me. But that may just be because I'm not familiar with the semantic release process.

[simenandre]

Actually, after looking at this a second time, I don't know how I thought release/* would work with the proposed config … 🙄

To further explain the configuration I proposed above. main will automatically release to main channel (e.g. v1.0.0, v1.0.1 etc.). develop would be develop channel (e.g. v1.0.0-develop.1, v1.0.0-develop.2). The develop channel would be marked with prerelease in Github and NPM. Essentially like canary releases.

Also, the +([0-9])?(.{+([0-9]),x}).x branch, would be used to maintain a version, such as v1 or v1.2. Let's pretend that we have moved on to v2, but we'd like to maintain v1, we'll create a branch named 1.x.x. Every push to 1.x.x would release new versions on v1. However, none of this actually works the way that Git Flow works for release/*, since they are branches meant to prepare for a release.

Developers would create a pull request with develop as the base branch. Once we are ready to release something for main channel, we'll merge it with main. We could use next for release candidates (and add a prerelease tag for that) as @NullableInt suggested? (e.g. v1.0.1-rc.1, v1.0.1-rc.2)

Better example

{
	"branches": [ 
	   	"+([0-9])?(.{+([0-9]),x}).x", 
	   	"main", 
		{
			"name": "next",
			"prerelease": "rc"
		},
	   	{ 
	     	"name": "develop", 
	     	"prerelease": true 
	   	} 
	]

PS: To support main as default branch, we have to make sure we are using Semantic Release 17.x. See: semantic-release/semantic-release#1581

I don't know how release/* should be mixed in here, since Semantic Release automatically does version bumping etc before it creates a tag. Thoughts?

[asbjornu]

In Git Flow +([0-9])?(.{+([0-9]),x}).x would be equivalent to support/* branches. From what I understand, we have no need for release/* branches. As long as we only do stable releases from tagged commits on main we can do all planned releases from the main branch and tag appropriately with a stable or pre-release tag as we see fit.

[simenandre]

I'll create a quick pull request with documentation, so we can review the changes there. 👍

[github-actions]

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀