`getNextVersion` seems to have no effect

[JammingBen]

I'm currently setting getNextVersion to something I want my next version to be, but the Release-PR being created still has an auto generated version based on the latest version.

I'm guessing this is happening due to the following lines: https://github.com/woodpecker-ci/plugin-ready-release-go/blob/main/src/index.ts#L156. Shouldn't it also include a check if the user wants to overwrite the version via getNextVersion? Like this:

if (!isReleaseCommit && !nextVersion) {
  nextVersion = getNextVersionFromLabels(latestVersion, config.user, changes, shouldBeRC);
}

So it respects the user config getNextVersion? Or am I misunderstanding that config?

What I'm basically trying to achieve: Let's say I am on version 3.0.0 on my main branch and on version 2.1.0 on a stable branch that I'm still updating with patches. Now I want the plugin to create a 2.1.1 release from the stable branch. I thought I can achieve this via the getNextVersion config. But the next version in this example is always 3.0.1.

[anbraten]

Yep, that seems to be a bug. I would suggest we change

plugin-ready-release-go/src/index.ts

Line 70 in 6dff1a2

let nextVersion: string | null = config.user.getNextVersion ? await config.user.getNextVersion(hookCtx) : null;

to be always null:

let nextVersion: string | null =null;

And line

plugin-ready-release-go/src/index.ts

Line 157 in 6dff1a2

nextVersion = getNextVersionFromLabels(latestVersion, config.user, changes, shouldBeRC);

to be

if (!isReleaseCommit) {
  nextVersion = config.user.getNextVersion ? await config.user.getNextVersion(hookCtx) : getNextVersionFromLabels(latestVersion, config.user, changes, shouldBeRC);
}

as the next version isn't used before.

What do you think? Would you be open to create a PR for that bug?

[JammingBen]

What do you think? Could you open a PR for that bug?

Sounds reasonable. Will do, thanks for your input!

Following up on this scenario:

What I'm basically trying to achieve: Let's say I am on version 3.0.0 on my main branch and on version 2.1.0 on a stable branch that I'm still updating with patches. Now I want the plugin to create a 2.1.1 release from the stable branch. I thought I can achieve this via the getNextVersion config. But the next version in this example is always 3.0.1.

Fixing this will probably fix the version, but then I still have unrelated changelog items in my release, right? Because the changelog items are being gathered based on the latest tag (which would be 3.0.0 in the example above). But in my scenario, I only want items between 2.1.0 and 2.1.1 to be included. Any idea how to achieve this? Maybe add an option to set the latest tag manually?

[anbraten]

Actually I thought it would support backporting / stable branches 🤔 By looking on the code I guess this happens as it always compares the latestTag to your current branch / release-branch. I have no idea how we could automatically detect which branch / tag it should compare to apart from the latest. We could think of adding another hook that allows you to manually set latestTag, so you could maybe get it from a file or from the branch name and compare based on that 🤔 In that case with the correct commits being analyzed the nextVersion should also be correct again.

plugin-ready-release-go/src/index.ts

Line 112 in 6dff1a2

from: latestTag,

[JammingBen]

Actually I thought it would support backporting / stable branches 🤔 By looking on the code I guess this happens as it always compares the latestTag to your current branch / release-branch.

My assumption was mostly by reading the code. I'll give it a try with this new fix and see what's happening.

We could think of adding another hook that allows you to manually set latestTag, so you could maybe get it from a file or from the branch name and compare based on that 🤔

Yep that's what I had in mind, too. I can't think of a more elegant solution, though obviously I'm not that deep into the codebase 😅 Again, I'll test it and come back if it doesn't work. In any case we would love to have some solution for this because we have several repositories with stable branches that receive backports from newer versions. I'd be happy to implement it if necessary.

[JammingBen]

Just tested - version looks good now, but as expected the changelog items are not quite correct.

We could think of adding another hook that allows you to manually set latestTag, so you could maybe get it from a file or from the branch name and compare based on that 🤔 In that case with the correct commits being analyzed the nextVersion should also be correct again.

If you decide to go that route, just drop me a sign, I'll happily add it. Especially the last point you mentioned would be nice for us since we would not need the extra getNextVersion config.

[anbraten]

If you decide to go that route, just drop me a sign, I'll happily add it. Especially the last point you mentioned would be nice for us since we would not need the extra getNextVersion config.

Seems to be our best option right now. We could test it a bit before doing the next release and check if it fixes your use-case.

[klinux]

Hello, how can I configure getNextVersion in the release-config.ts?

[anbraten]

You can specify getNextVersion: (ctx: HookContext) => PromiseOrValue<string>; in a release-config.ts file.

[klinux]

Hello @anbraten do you have an example?

I created this, but I think this is not good:

    getNextVersion: ({ nextVersion, bump }) => {
        // Provide a default version if nextVersion is undefined
        if (!nextVersion) {
            nextVersion = '0.14.0';
        }
        const match = nextVersion.match(/^(\d+)\.(\d+)\.(\d+)$/);
        if (!match) throw new Error(`Invalid version format: ${nextVersion}`);
        let [_, major, minor, patch] = match;
        major = parseInt(major);
        minor = parseInt(minor);
        patch = parseInt(patch);

        if (bump === 'major') {
            return `${major}.${minor}.0`;
        } else if (bump === 'minor') {
            return `${major}.${minor}.0`;
        } else {
            return `${major}.${minor}.${patch + 1}`;
        }
    },