Publish to a distribution branch

[josecelano]

This is a question because I do not understand part of the README.

In the README these are the steps describing how to publish a new release.

$ npm run package
$ git add dist
$ git commit -a -m "prod dependencies"
$ git push origin releases/v1

The GitHub documentation is a little bit confusing for me. It is supposed you can release new versions using tags or branches. I suppose in this template you have chosen a concrete strategy. I would like you to confirm if I'm right about your proposed release management process and also be more explicit about that in the README.

This is how I understand your proposal to manage releases:

• You do not include the built app in every commit. I mean the dist folder. This way you encourage people to use only published versions.
• You are using branches instead of tags. I mean, releases/v1 is a branch.
• releases/v1 is a beta branch. At some point when you consider it stable, you create the tag 1.0.0 on the main branch.
• I suppose the check-dist.yml should fail always except when you build a new app version.

I'm using this template and we have been discussing this topic. The link you have added does not make things much clearer to me.

[ncalteen]

Hello! Apologies for the delay in responding to this issue. I am working on updating this repository, including clarifying the instructions in the README. You can check out #732 for the proposed README and other changes!

Regarding your questions, a few comments below:

• When releasing GitHub Actions, developers can use your action by referencing it by commit SHA, branch, or tag. Any of the following would work, for example:

  - uses: actions/upload-artifact@v3 # tag
  - uses: actions/upload-artifact@main # branch
  - uses: actions/upload-artifact@0b7f8abb1508181956e8e162db84b466c27e18ce # sha

• Currently this repository does not enforce or propose a release strategy. Since many teams can do it different ways, we purposefully left that open for customization :)

• The transpiled action code should always be updated in dist on every push to main (or PR targeting main). There is a workflow in this repo that checks specifically if that has been done.

• We are using branches, yes, but are following GitHub flow. In GitHub flow, branches are not kept long-term. Once a feature is developed and the PR is approved/merged, the branch is deleted and the merge commit is tagged with an appropriate release version (e.g. v1.0.0). However, this is one of many valid strategies for managing releases.

If there are other questions we can help out with, please feel free to reopen and reply!