A Github action to calculate the next CSDA version for the checked-out repository.

To use with release-please:

  steps:
    - name: CSDA Version
      id: csda-version
      uses: NASA-IMPACT/csda-version@<hash-version> # hash-version is recommended for extra security 
    - uses: googleapis/release-please-action@<hash-version> # hash-version is recommended for extra security
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
        release-type: simple
        release-as: ${{ steps.csda-version.outputs.version }}
        config-file: ${{ steps.csda-version.outputs.release-please-config }}

To see this in action, check out https://github.com/NASA-IMPACT/csdap-frontend/blob/main/.github/workflows/release-please.yml.

A CSDA version is formatted like vYY.PI.SP-X, where:

• YY is the last two digits of the year,
• PI is the "program increment", which is like a normal calendar quarter except that PI 1 starts Oct 1
• SP is the sprint number
• X is the release number in this sprint

Release Please only recognizes feat and fix commit prefixes when generating automated releases.

git commit -m "feat: add user authentication"
git commit -m "fix: merge conflicts"

Appending an exclamation mark (!) to the prefix will add a BREAKING CHANGES header to the changelog. Use this sparingly and only for changes that introduce backward incompatibility.

For other standard commit types (such as refactor, chore, docs, or revert) pass them as a scope to feat or fix. If you need to trigger a release use:

git commit -m "fix(chore): update dependencies"
git commit -m "feat(docs): add new documentation"
git commit -m "feat(chore)!: breaking change in dependencies"

Note: Commits without feat or fix prefixes will not trigger a new release, but they will still appear in the changelog.