Skip to content

Introduce release workflow #104

@widhalmt

Description

@widhalmt

Since I'm more an engineer and less a developer, I want to put ideas up for discussion. How about the following:

  • As soon as we tag 1.0.0 we introduce a support/1.x.y branch. Whenever we add non breaking changes to the repository, we merge into that instead of main. If the merge succeeds, we merge this support branch into main
  • When we introduce breaking changes, we merge directly to main
  • When we see the time coming for a new major release, we start a rc/2.x.y branch. Non breaking changes from support will also be merged into this branch
  • When all issues targeting the new release are closed, we tag rc1 from the rc branch. We'll ask users to test this rc and report issues. When all these issues are fixed, we'll tag rc2and so forth. Only when there are no changes besides docs and comments, the last RC will be tagged as the new release
  • We aim on supporting the current major release and the last major release
  • The rest is documented as "semantic versioning"

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationhelp wantedExtra attention is neededquestionFurther information is requested

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions