Speed up release cycles ♻️

[JamieSlome]

Observations 👀

Our current release cycle is slow and is unduly held up by the implementation of large changes sets. In order to release new features and bug improvements today, we use the published GitHub event via GitHub releases to trigger an NPM publication.

This can be found in our GitHub workflows here 👈

Requirements 📝

In order to speed up our release cycles and follow open source best practices we should:

Tasks

Beta Give feedback

1. Follow semantic versioning based on type of improvements to main
2. Increment the version of the library based on some change set (automatically if possible)
3. Automatically publish to the NPM registry once a version update is detected

[JamieSlome]

@eddie-knight @maoo - just pinging you for your awareness! 👍

[maoo]

Thanks @JamieSlome - checkout #534 , it probably checks all your boxes.

In parallel, can we set some target dates for future releases?

1.3.0 - reconciled code - May 3rd
1.4.0 - CLI and API - May 31st
2.0.0-alpha - plugins and much more - September 27th

@coopernetes @msagi @JamieSlome - did I miss any important milestone? you think that dates are realistic?

[JamieSlome]

@eddie-knight - looks like the GitHub automatic versioning works nicely 👍

Not sure why the NPM publish failed?

On a side note, should we add an ignore list for files like .github as we likely don't want to release for these?

[JamieSlome]

@eddie-knight - fabulous job on this and appreciate the follow up minor improvements ❤️

@TheJuanAndOnly99 @maoo - are we able to make PR / Validate & Label PR (pull_request_target) a required status check for pull requests?

[maoo]

@eddie-knight - fabulous job on this and appreciate the follow up minor improvements ❤️

@TheJuanAndOnly99 @maoo - are we able to make PR / Validate & Label PR (pull_request_target) a required status check for pull requests?

Done!