[QUESTION] - does not calculate next patch version

[DmitryEfimenko]

I've read the description of the project and quite a bit of other issues to understand that the version is calculated based on tags. From what I can see I have the right tags in place. And I have one "docs" commit that's pending the release. However, it does not seem to be able to calculate next tag:

> git tag -l
expandable-input-1.0.0
expandable-input-1.0.1

> git log
commit 7d53f3817d1331129f51d31e7fe394da106f28e2 (HEAD -> fix/tag)
Author: Dmitry <dmitrief@gmail.com>
Date:   Mon Jan 2 22:22:23 2023 -0700

    docs(expandable-input): 📘 release with latest tag

commit fe729878306c661d213c75d95dbd6bbbcb61002c (origin/main, origin/HEAD, main)
...

> npm run nx -- -- version expandable-input --dryRun true
nx version expandable-input --dryRun true

> nx run expandable-input:version --dryRun true

[expandable-input] 🆕 Calculated new version "1.0.1".

---
### [1.0.1](https://github.com/DmitryEfimenko/ngspot/compare/expandable-input-1.0.0...expandable-input-1.0.1) (2023-01-03)
---

I saw that some people may have some difficulties depending on the git workflow. I'm running this command off of a feature branch. Not main. Not sure if it has anything to do with anything.

I also tried adding releaseAs=patch and --allowEmptyRelease=true but there was no difference.

Here's the repo where I'm running this in case you need to see the configuration.

I'm sure I'm doing something silly and missing something simple. But I spent a whole day trying to figure this one out. Any help is appreciated!

[fernandofmarte]

I feel like I'm running into a very similar issue. I'll try to recreate the repo because i'm working on a private one. I'm on a branch, testing this out. I'm trying to create the next pre-minor release , after create my first one. To create it the first time, I did:

nx run player:version --trackDeps --push --releaseAs=preminor --preid=preminor --baseBranch=BDVP-3150-integrated-repo

Now, I had a tag:

> git tag -l              
player-0.1.0-preminor.0
> git st    
On branch BDVP-3150-integrated-repo
Your branch is up to date with 'origin/BDVP-3150-integrated-repo'.

nothing to commit, working tree clean

My last commit had a feat commit:

> git log
commit b63db0ed76121125f7c2cda3bba7ad780c5254c3 (HEAD -> BDVP-3150-integrated-repo, origin/BDVP-3150-integrated-repo)
Author: Fernando Marte <fernando.marte@mlb.com>
Date:   Tue Jan 10 15:13:28 2023 -0500

    feat(player): trying again to update release again

commit fa72e1e8a26ac96f2abfc4a222e7a9f0bf61df60
Author: Fernando Marte <fernando.marte@mlb.com>
Date:   Tue Jan 10 14:53:53 2023 -0500

    chore(player): release version 0.1.0-preminor.0

I would think that if I run the top command again, it should bump it, but doing a dry run, it never does:

nx run player:version --trackDeps --push --releaseAs=preminor --preid=preminor --baseBranch=BDVP-3150-integrated-repo --dryRun                    

> nx run player:version --trackDeps --push --releaseAs=preminor --preid=preminor --baseBranch=BDVP-3150-integrated-repo --dryRun

[player] 🟠 No previous version tag found, fallback to version 0.0.0.
        New version will be calculated based on all changes since first commit.
        If your project is already versioned, please tag the latest release commit with player-x.y.z and run this command again.
[player] 🆕 Calculated new version "0.1.0-preminor.0".

---
## [0.1.0-preminor.0](https://github.mlbam.net/web-media/mlb-stories/compare/player-0.1.0-preminor.0...player-0.1.0-preminor.0) (2023-01-10)

### Features

* **player:** trying again to update release ([4f083f7](https://github.mlbam.net/web-media/mlb-stories/commit/4f083f7f3be04a12868b2e937600047f14725340))
* **player:** trying again to update release again ([b63db0e](https://github.mlbam.net/web-media/mlb-stories/commit/b63db0ed76121125f7c2cda3bba7ad780c5254c3))
---

[player] 📜 Generated CHANGELOG.md.

 —————————————————————————————————————————————————————————————————————————————————————

 >  NX   Successfully ran target version for project player (1s)

         With additional flags:
           --trackDeps=true
           --push=true
           --releaseAs=preminor
           --preid=preminor
           --baseBranch=BDVP-3150-integrated-repo
           --dryRun=true

I don't get if I'm missing a step somewhere to see get the the library to bump the tag. Am I supposed to manually create the tag, or does this handle it?

[DmitryEfimenko]

I think what happened in my case is that when I pushed my feature branch, it pushed the tag as well. Then I created a PR from my feature branch to a new branch and merged that PR. I think I might have chosen an option to create a new merge PR or may have chosen to squish commits, but in the result the tag didn't point to the right commit and that's what was causing the issue.

To fix it, I manually deleted the tag on the remote and re-created it pointing to the right commit. After that it was able to figure out right version.

I feel like this repo needs to provide separate set of instructions on using this repo with git workflow.

[fernandofmarte]

Thanks for replying back @DmitryEfimenko . I just started testing out NX and this plugin, so I haven't tried merging PRs. What I am doing is working on a "release candidate" branch, instead of "main". Our git workflow is:

1. Create an 'release-candidate' branch off 'main'.
2. Create feature branches off 'release-candidate' to work on bugs/features
3. Merge feature back into 'release-candidate' and version a pre-release version of that for testing on our beta env.
4. After everything looks good for a sprint, then we merge the 'release-candidate' into 'main', publish that and push that out to prod.

So in my example above, just for testing, I'm treating the 'BDVP-3150-integrated-repo' branch as a 'release-candidate' branch.

So that's why I want to make sure this plugin could handle creating the version and tag and pushing it out for us. It seems to work the first time and it creates the tag, but no matter what I try, the current tag isn't being picked up so then the next one isn't being created properly.

Any help would be appreciated. Thanks again.

[edbzn]

Hi, semver was not designed to work with these types of git flows, we recommend running semver only on the main branch. The problem you are facing is the following: when merging the release-candidate branch into main, it creates a new commit on your main branch, but the tag created by semver points to the old commit (not the one resulting from the merge), so semver cannot reach the tag when you release again. To fix your issue you can write a script that find tags present on the release-candidate branch, and force update them to point to the main branch whenever you merge, so semver will detect them.

[DmitryEfimenko]

thanks for the reply! The git workflow is a common practice. Do you think the functionality you described would be a good feature for this library?

[edbzn]

I used git flow before and I'm not a fan, I prefer having as less branches as possible. In fact, when we created semver, we followed the continuous integration pattern, that's why it is a bit opinionated on the branching model. Changing this would require introducing dirty hacks, and I'm not sure it's worth it. That says I know some users are facing this issue, and I'm planning to rewrite semver totally, it may be the occasion to rethink how things work so it can be easier to support different workflows.

[minuz]

Thanks for the clarification @edbzn.