NYX FILTERTAGS PROBLEM

[lxke19]

Hey @flelli ,

below you can see our nyx-Configuration which is working fine. But we found one bug or problem, maybe u can tell us if there's already a solution for this, or if this should work like this.

If I create a new Branch for example: feature/nyx on the main Branch with the current tag 3.4.0. Then i commit for example: "feat: nyx implemented" then it infers the version: 3.5.0-featurenyx.1 which is correct!

Now the Problem: If meanwhile someone creates a new "main-" Tag 3.5.0. Nyx still infers the version 3.5.0-featurenyx.1 but should search for all new tags, find the 3.5.0 tag an infer 3.6.0-featurenyx.1

How can I tell nyx it should look after the actual version and not the version the branch is created on?

Thanks in advance,

Luke

override fun apply(project: Project) { project.pluginManager.apply(NyxPlugin::class.java) project.extensions.configure(NyxExtension::class.java) { nyxExtension -> nyxExtension.preset.set("simple") nyxExtension.dryRun.set(false) nyxExtension.releaseLenient.set(true) nyxExtension.git{ git -> git.remotes{ remote -> remote.create("origin"){ origin -> origin.authenticationMethod.set("...") origin.user.set(System.getenv("...")) origin.password.set(System.getenv("...")) } } } nyxExtension.releaseTypes { releaseType -> releaseType.enabled.set( listOf( "mainline", "feature" ) ) releaseType.items { item -> item.create("mainline") { mainline -> mainline.collapseVersions.set(false) mainline.filterTags.set("^()?([0-9]\d)\.([0-9]\d)\.([0-9]\d*)") mainline.gitCommit.set("true") mainline.gitCommitMessage.set("Release version") mainline.gitPush.set("true") mainline.gitTag.set("true") mainline.gitTagMessage.set("Tag version") mainline.matchBranches.set("^(master|main)$") mainline.versionRangeFromBranchName.set(false) mainline.publish.set("true") }

                item.create("feature") { feature ->
                    feature.collapseVersions.set(true)
                    feature.collapsedVersionQualifier.set("{{#sanitizeLower}}{{branch}}{{/sanitizeLower}}")
                    feature.filterTags.set("^()?([0-9]\\d*)\\.([0-9]\\d*)\\.([0-9]\\d*)(-{{#sanitizeLower}}{{branch}}{{/sanitizeLower}}(\\.([0-9]\\d*))?)?$")
                    feature.description.set("Feature Release")
                    feature.gitCommit.set("true")
                    feature.gitPush.set("true")
                    feature.gitTag.set("true")
                    feature.matchBranches.set("^(?!(master|main)$).*")
                    feature.publish.set("true")
                    feature.versionRangeFromBranchName.set(false)
                }
            }
        }
    }
}

[flelli]

Hi @lxke19 ,

that's by design as Nyx starts from the HEAD commit and goes backward following the first parent in case of merge commits. A few examples here.

The type of consistency checks you mentiond would fail in any case if only, for example, one forgets to fetch changes that other contributors may have done in the meanwhile.

Moreover, due to SemVer semantics, the case sould be avoided, regardless the tool you use, if any.

This is simply to say that you need a branching model/strategy for that and tools like Nyx can't help unless you have a clear shared strategy. On the other hand, if you have that strategy and follow a clear process aboud merging, committing and branching, that case never happens.

[lxke19]

Hey @flelli ,

But why doesn't it work even if i merch the Main line in my branch? Shouldn't it have the latest commits then? But it still ignores them?

Tanks in advance,

Luke

[flelli]

@Hi @lxke19 , that's due to the "first parent" criteria. If you merge main into newbranch the first parent is newbranch so the history will be scanned in newbranch.

If, instead, you merge newbranch in main, main is the "first parent" branch where the history is evaluated from.

[lxke19]

Hey @flelli , si if im understanding u right.

I have the Main Verion 2.0.0 Make a New Branch 2.1.0-nyx 2.2.0-nyx 3.0.0-nyx 3.1.0-nyx And merge it back into the Main, nyx would Inferno the New Main Version as 3.0.0? Is this right?

[flelli]

Yes, as long as the merge commit has a message that tells Nyx to bump the major number (i.e. feat!: something).