Add option to add `last-release` tag

The last-release tag should always be on the commit with the latest (as in time, not version-number) release. The tag is used to calculate the changes since the last release.

Currently I’m setting the tag as an extra CI-step, but this has the disadvantage that the tag will be moved whether there is a new release or not.

The best way I came up with would be to set the last-release tag in the same step the version tag for the individual release is set. If wanted there could be a global config where this behavior could be enabled/disabled.

[ndrsg]

the downside of “moving” the “last-release” tag is that you always have to

git pull -t -f

before pushing, to update the tag locally.

To avoid that, im pushing a new tag, starting with release- , followed by a number, or a date and time like

git tag -f release-$(date '+%d-%m-%Y-%H-%M-%S')

to get the base for the next nx affected, im using

npx nx affected --target=prepare --base=$(git show-ref --tags | grep release- | tail -n 1 | sed 's~.* refs/tags/~~')

IMHO, this is a bit out of scope of versioning, and more an individual CI flow thing when / how to place a last-release tag.

Another possibility would be to “grep” for the newest version-tag (that depends on your configuration).

e.g. if you

{
 "tagPrefix": "release-${projectName}-"
}

you could also use

git show-ref --tags | grep release- | tail -n 1 | sed 's~.* refs/tags/~~')

to get you base, and you dont have to push an extra tag at all, BUT

if a library/app fails versioning for some reason (upload fails?), you cannot retry you build.

[yjaaidi]

Exactly! This can only work at the workspace level. Also, what I meant is that this is beyond semver. All kind of workflows using affected need a way of marking the last success. We could even imagine multiple tags for multiple steps:

nx affected --target test --base last-test-success
nx affected --target version --base last-version-success

Actually, it should be an Nx feature. 🤔 just thinking out loud, what about a hook system that could allow us to trigger an executor after nx affected…

Or maybe, we just need an Nx wrapper for the CI. npx nx-affected-and-tag --target test