Go repositories with multiple versions

[BatmanAoD]

Go repositories with multiple versions

[BatmanAoD]

Here are some of the package configs I tried with Gax:

[packages.v1]
versioned_files = ["go.mod"]
scopes = ["orig"]

[packages.v2]
versioned_files = ["v2/go.mod"]
scopes = ["current"]

[packages.orig]
versioned_files = ["go.mod"]

[packages.current]
versioned_files = ["v2/go.mod"]

[packages.orig]
versioned_files = ["go.mod", "v2/go.mod"]

[dbanty]

The complexities of the Go module system will never end 😆. Which of those example syntaxes would be best? I assume if both v1 and v2 are in the same branch, you'll want to be able to version them independently regardless of what the most recent tag was—so I assume they should be separate packages so that commit scopes or changeset metadata can target only the relevant piece... so that'd be the first config, right?

[BatmanAoD]

Yes, I think the first config is what makes the most sense; thanks!

[dbanty]

@BatmanAoD I think #591 has the right behavior now, but please test it out!

[BatmanAoD]

Hm, dry-run works but it seems that an actual release doesn't. I've forked Gax and set up the main branch to demo a simultaneous release of both versions: https://github.com/BatmanAoD/knope-gax

Here's the behavior I get using this branch:

❯ : ~/personal/knope/target/release/knope release --dry-run
Would run git commit -m "chore: prepare release"
Would create Git tag v1/v1.0.3
Would create Git tag v1.0.3
Would create Git tag v2/v2.0.5
Would create Git tag v2.0.5

❯ : ~/personal/knope/target/release/knope release
Error:   × Problem with workflow release

Error: releases::no_release (link)

  × No packages are ready to release
  help: The `PrepareRelease` step will not complete if no changes cause a package's version to be increased.

(--verbose has a lot more info, but I recommend just checking out that fork and trying it yourself. I've configured knope.toml not to push changes back.)

[dbanty]

Okay, so there are several weird things overlapping here.

First, the commits added to that branch had quotes around the messages, so the prefixes were being parsed wrong. For example, there was the message "fix(v1): knope test" which meant the commit type was "fix (instead of fix), so it had no impact on the version.

Second, and I'm not sure how to resolve this, PrepareRelease does not error out if there is nothing to release when run with --dry-run, since the intention is that folks will run this regularly in CI to check on results before merging (since before the allow_empty option and the new pull request workflow). Normally, the release step would indicate that there's nothing to release... except:

Third, even though I taught Knope to use the right tags for determining go mod versions, it still uses its own tagging syntax for deciding when the last release was (that's the ugly v1/v1.0.3 syntax. Combined with the recent feature to let Release run without PrepareRelease, we get this awkward state where Knope decides that there has not been a release of this package (no v1/v* tag), so it tries to create one for the latest version, assuming that a PrepareRelease was run separately. I think I'm going to have to adjust the logic to look at the entire workflow, and only try to autodetect releases if PrepareRelease did not run.

So, I got this to work by:

1. Reset to the place where knope.toml was added, before the new commits
2. Create the package tags of v1/v1.0.3 and v2/v2.0.5
3. Reapply the fix/feat commits (without extra quotes)
4. Run knope release, which now creates all these tags on the new commit: v2/v2.1.0, v2.1.0, v1/v1.0.4, v1.0.4

This does have me thinking, though, that this multi-package workaround for multiple major Go versions may not be good enough. I might need to add some new config syntax that correctly supports multiple major versions for one package (without the extra ugly tags). At very least, I should add some better docs about how to onboard an existing multi-version Go package (by manually creating the ugly tags once).

[dbanty]

Here's an idea for a config syntax for supporting multiple versions of the same package:

[package]
versioned_files = ["go.mod"]
scopes = ["v1"]
changelog = "CHANGELOG.md"

[[package.additional_versions]]
major = 2
versioned_files = ["v2/go.mod"]
changelog = "v2/CHANGELOD.md" # If not provided, same as parent
scopes = ["v2"]  # If not provided, uses same scopes as parent

Which, for the multi-package syntax, would then be like [packages.knope] and [[packages.knope.additional_versions]].

Thoughts on that? Ideas for something better? I'm trying to find some examples of non-Go projects which have multiple versions coexisting on the same Git branch to see if there's anything I'm missing.

[dbanty]

Oh, also, I think I messed up the v2 support for submodules. If you have go.mod, then you also have v2/go.mod for 2.*. But if you have my_package/go.mod, would v2 be in v2/my_package/go.mod or my_package/v2/go.mod?

[BatmanAoD]

Ahhh, dangit, I keep running into the quoted-comments issue for a pretty idiosyncratic reason:

• I somehow developed a habit of making git commits using git commit -m"some message", rather than -m "some message" or "-msome message" (both of which also work).
• I am trying to transition to Nushell as my primary shell.
• Nu handles quoting fairly differently from POSIX, and in this case quotes are not stripped from -m"some message", whereas POSIX shells do strip them (producing the literal string -msome message).
• I'm trying to train myself to put a space after -m, but I don't really have a good feedback loop here! Git doesn't care that the actual message string has quotes in it.

[BatmanAoD]

I don't really know how submodule versioning works, sorry... not something I've really tried to use much.

[dbanty]

Alright, well I'm going to use my best guess then!