-
Notifications
You must be signed in to change notification settings - Fork 15
Go versioning: add support for maintaining multiple versions within a single repository #253
Comments
Worth noting that, at least as far as Go is concerned, tags apply to modules - not repositories. So, intuitively, I would expect one That vision is somewhat Go-centric though. If we prefer always a top-level |
My vote is version file next to |
Assuming that versioning will be following the language in question, I think I do agree with |
A note from the Rust world. You can also have multiple packages (called crates) within a single repository. There is a root |
Putting a Am I right to assume that if you have multiple versions (like |
Yes the major version compatibility is checked. You can try
|
@marten-seemann your understanding is about right. There are four basic rules:
More details in https://go.dev/ref/mod#vcs-version and the rest of that doc. But hopefully my summary helps get a high-level picture. I know the rules seem complex and arbitrary, but you need all of this to support all reasonable workflows - including monorepos - without forcing all modules inside the same repository to always share all versions. |
@mvdan Thank you for the detailed explanation!
Interesting. I didn’t know that tags like these were even possible (or rather, valid semver tags). We’ll need to modify the workflows such that they don’t only trigger on |
I think that's been fine so far, because the so-called "nested Go modules" are generally discouraged unless you're going for a proper monorepo. They are rare at PL, given that practically nothing uses monorepos at the moment. There are some examples of nested modules, such as go-car/cmd and go-ipld-prime/storage/bsadapter, but note that noone has released tagged versions for those yet. If they had, they would have beem of the form
That sounds right. You want to allow an optional "subpath prefix" as well. But then we'll also need to properly navigate into the nested module to look at the right go.mod file (and possibly its separate version.json file). |
This issue was transferred to ipdxco/unified-github-workflows#40 in preparation for archiving of this repository. |
Extract from a conversation with @masih:
There are some multi-module repositories that maintain multiple versions on the same branch. The ask here is to handle both root level
version.json
file andversion.json
files from subdirectories if they exist.One could update either of the
version.json
files for the new tag to be created. Maintainers are aware that tags can’t clash.Example repo that would benefit from such setup:
https://github.com/ipld/go-car
https://github.com/ipld/go-car/tree/master/v2
Alternatively: maybe the root level
version.json
could be structured in a way that would support multiple versions.The text was updated successfully, but these errors were encountered: