search

eik-lib / issues

Issues and discussions that span all of Eik
https://eik.dev
1 stars 0 forks source link

RFC 3 - Establish a workflow for releases #3

Open trygve-lie opened 3 years ago

trygve-lie commented 3 years ago

To be able to develop and deliver more comprehensive releases we should establish a workflow we adhere to. Currently we have been using semantic release to cut releases for us from the CI. Semantic release do have a suggested workflow regarding releasing: https://github.com/semantic-release/semantic-release/blob/0785a844fa8ac1320383452ce531898be3b01f92/docs/recipes/pre-releases.md

Is the above workflow a flow we can adhere too and is there other aspects we need to take into consideration?

gingermusketeer commented 3 years ago

That looks like a good place to start. To summarise:

A few open questions from my side after reading through the setup there:

  1. Did you want to stick with next instead of beta? Or is it better to go with beta so the semantic release guide is more relevant?
  2. Where will development dependencies be upgraded?
  3. Do we/can we skip releases for development dependency version changes?
  4. Should there be a schedule for merging changes from beta into master? Or would a bot command be better?
  5. Should non development dependencies be upgraded against the alpha branch if it is a major version change? What if they don't turn out to be breaking changes?
  6. Should there be a PR template setup which reminds folks and helps new comers to decide where to branch off?
  7. Does the update of alpha and beta branches from master need to be automated?
  8. Will beta and alpha releases of one module trigger the update of the dependency in the correct branch on other repos?
  9. Should any guide for this that is written up include description of major version changes across multiple repos?
  10. Perhaps useful for the guide to include configuration for renovate?
trygve-lie commented 3 years ago

Did you want to stick with next instead of beta? Or is it better to go with beta so the semantic release guide is more relevant?

The work we've done with next have been a bit simpler than using betaand alpha as a tool to split breaking changes. We've more used next as the branch to merge into what we want to become the next release and where the development might take a bit of time. That's made it easy for us to keep developing new stuff while being able to fix stuff in master. I have no strong opinion on next vs beta to be honest. Though, I find next to be very clear that this is the stuff which will be the next release.

Where will development dependencies be upgraded?

I wonder if both next and master should be updated. If we start pushing dev deps to next it might be that they are not updated due to a very long time. Or, next becomes a place where dependency updates die due to there is no active development in next for a while.

Do we/can we skip releases for development dependency version changes?

We are already skipping releases for dev deps. Renovate bot flags dev deps as not being a release worthy by semantic release.

Should there be a schedule for merging changes from beta into master? Or would a bot command be better?

By a schedule; do you mean fixed dates?

Should non development dependencies be upgraded against the alpha branch if it is a major version change? What if they don't turn out to be breaking changes?

I'm kinda thinking they should perhaps go into both here also. We've configured renovate bot so major must be manually merged so they should not slip through and make a breaking release by accident. And the test coverage should catch kinda major breaking stuff.

Should there be a PR template setup which reminds folks and helps new comers to decide where to branch off?

Personally I find these templates a bit more annoying than helpful. Though; we should have a document describing the development workflow. My opinion is also that we should keep the barrier as low as possible for newcombers. Its not like there is a ton of PRs being submitted each day so for now I think we can keep it as simple as possible for those who would like to contribute.

Does the update of alpha and beta branches from master need to be automated?

How will an automation of this deal with merge conflicts?

Will beta and alpha releases of one module trigger the update of the dependency in the correct branch on other repos?

Yes. Thats one of the things we tested very early. We wanted next releases to bump dependencies in the next branches and renovate bot handle this.

Should any guide for this that is written up include description of major version changes across multiple repos?

I do not think so. A user of ex the client should not need to know about API changes in @eik/common. If so, we're doing something wrong in how we split our code into modules.

Perhaps useful for the guide to include configuration for renovate?

Agree to that.

digitalsadhu commented 3 years ago

I'm thinking along these sorts of lines:

on master:

on next: