Would you consider adding major version tags?

[ezzatron]

Many actions provide major version tags (e.g. actions/checkout@v2). I'd love to be able to use JamesIves/github-pages-deploy-action@v4 instead of a specific patch version, in order to reduce the maintenance burden on repos that use this action.

Is this something you'd be willing to consider implementing?

[JamesIves]

You could just point your workflow to the release branch using JamesIves/github-pages-deploy-action@releases/v4 if you want to have the cutting edge changes from the major version, but I highly recommend against this for a few reasons. The first because there's often changes being made to that branch to prepare for a new release which may introduce breaking changes, and the second being because once the tag updates you'll have no choice but to use the new update, which could contain unexpected bugs. Unlike an npm dependency or something similar you need to perform the install step to get it to pick up a new update, with this it will be the next time you run it no matter what and it would be pretty frustrating if it broke your workflow.

It's almost always preferred that you manually bump the changes yourself and observe what is in the patch notes to make an informed decision about what is in the new release, especially when it comes to your deployment workflow. Assuming you're not using this with GitHub Enterprise, to limit the maintenance required for this you can setup a .github/dependabot.yml file in your repository with the following to enable automated Dependabot updates.

version: 2
updates:
  - package-ecosystem: github-actions
    directory: '/'
    schedule:
      interval: daily

With this you'll get automated pull requests like this which you can just merge to pick up the latest changes.

I acknowledge there's a difference between using the release branch vs major version tagging, but many of these concerns still hold over. Pointing users to a major tag was something that was done in the past when Dependabot updates were not available for GitHub Actions and it became problematic for some users.

[ezzatron]

Thanks for the reply. For what it's worth, I already use Dependabot to manage the updates for actions. This action just stands out as the only one I use that doesn't provide a major version tag, and hence I get a lot more Dependabot spam because of it.

I'd like to make a counter-point about the comparison to NPM dependencies. In my projects, I usually do not commit any kind of lock file for NPM, so it's completely normal for dependencies to have new versions in between workflow runs.

The reason this practice doesn't descend into madness is because the NPM packages all use SemVer to version their releases. They guarantee backwards compatibility within a major release, which means I don't have to read the release notes of every single patch release to know if it's going to work. I don't get notified about dependency releases unless there's a new major version. When there is a new major version, Dependabot notifies me about it, and I can assess the backwards compatibility breaks.

So I guess what I'm asking for is not just major version tags, but a commitment to SemVer-style versioning. It doesn't help to just create major version tags if the version numbers have no specific guarantees associated with them, and BC breaks are allowed to occur in minor or patch versions.

[JamesIves]

Semantic versioning is followed as closely as possible. The problem is when something unintentionally breaks. As there's a lot of use cases that span over a lot of users it can be difficult to keep up if something breaks as the result of a bug if everyone is pointing to a major version tag as opposed to a specific version. On paper it seems fine, but having very little help when it comes to quality assurance outside of unit and integration tests it worries me as I could become very quickly overwhelmed if something is missed.

I'm happy to add major version tags as an option but I'm cautious about advertising them at this minute in the README. The publishing workflow is what it used to push the version on to both the npm and GitHub registries, so either that or another workflow may need to be created to accommodate this change.

[JamesIves]

Major version tags are now available as an option: JamesIves/github-pages-deploy-action@v4

These are automated via the workflows/version.yml job.

[ezzatron]

I totally appreciate your caution, and the concern about getting overwhelmed. Even on some smaller OSS repos of mine I feel the same thing, and I can also understand how something that's responsible for publishing everyone's website would be extra nerve-racking.

If the major version tags end up causing you too much grief, don't worry about it. But I'll definitely use them so long as they're available. Thanks for putting together a great tool, and thanks for taking my feedback on board 👍

[JamesIves]

No problem! They'll remain active, thanks to GitHub Actions the whole process of generating the major version tags is automated anyway.

Have a good one!