Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module versioning #821

Open
lerno opened this issue Jul 6, 2023 · 8 comments
Open

Module versioning #821

lerno opened this issue Jul 6, 2023 · 8 comments
Labels
Discussion needed This feature needs discussion to iron out details Enhancement Request New feature or request

Comments

@lerno
Copy link
Collaborator

lerno commented Jul 6, 2023

Consider some versioning scheme for various elements in the build/manifests:

Possible design:

  1. Dependency contains no-version, major version, minor version, major + minor + build or list of major versions
  2. Try to resolve the major version to use. If none is selected, pick max. More than one are required -> compile error
    (example: A needs 1, 2, B needs 2, 3 => pick 2, A needs 1, 2, B needs 3, 4 => error)
  3. Pick the maximum minor + build version available. If this is less than minimum minor + build version needed => error.
  4. Excluding versions should be possible, eg exclude 1.3.4
@lerno lerno added Enhancement Request New feature or request Discussion needed This feature needs discussion to iron out details labels Jul 6, 2023
@lerno
Copy link
Collaborator Author

lerno commented Jul 6, 2023

Go Modules work like this:

  1. Build file contains required library versions: e.g. 2.5.7
  2. First number is major version number and is considered incompatible (basically a different module completely)
  3. Dependency resolution per major library version is done by picking the minimal version. E.g. module Foo requires Bar 1.5+ and module Baz requires 1.3+. Our module using Bar and Baz will resolve the minimal version to 1.5. This is the version that will be used. Note that if Foo used 2.5+, then both Bar 2.5 and 1.3 would be required.

@pierrec
Copy link
Contributor

pierrec commented Jul 7, 2023

3. Dependency resolution per major library version is done by picking the minimal version. E.g. module Foo requires Bar 1.5+ and module Baz requires 1.3+. Our module using Bar and Baz will resolve the minimal version to 1.5. This is the version that will be used. Note that if Foo used 2.5+, then both Bar 2.5 and 1.3 would be required.

You mean Bar and Baz resolve to 1.3 right?

How would the version be specified? only in the project or other manifest file or in the module path as is the case in Go?

@lerno
Copy link
Collaborator Author

lerno commented Jul 7, 2023

No, they resolve to 1.5 since Bar needs 1.5+. Different major versions are considered distinct libraries.

@lerno
Copy link
Collaborator Author

lerno commented Jul 7, 2023

Module would be defined in manifest.json / project.json. A simple scheme is saying -lib foolib grabs any foolib -lib [email protected] means foolib 1.5+ etc:

Ideally look up if there is some standardized way to do the above.

@lerno
Copy link
Collaborator Author

lerno commented Jul 7, 2023

@pierrec
Copy link
Contributor

pierrec commented Jul 8, 2023

Maybe also have a look at what Zig si doing. They have introduced their package manager recently (I havent looked at it yet).

@lerno
Copy link
Collaborator Author

lerno commented Jul 8, 2023

I am not really looking at a package manager. I think downloading dependencies using other means is fine. Because of how C3 libraries work (essentially zip files with some metadata) they're easy to just drop manually into any project - no package manager needed. The only thing that's necessary is to determine how to select a package if you have dropped two libraries of the same type into your dependencies. Basically "what does that mean" when you then want to include a library.

Because we're not doing package dependency resolution for pulling in packages, we're essentially only about selection.

So say that you have your code, and then you drop in [email protected] [email protected] [email protected]?

So for example it could work like this:

  1. You just write --lib foolib => use the latest, 2.3.0
  2. You write --lib foolib@1 => use the latest 1.x => 1.5.1
  3. You write --lib [email protected] => use 1.5.0
  4. You write --lib foolib --lib barlib and barlib depends on 1.5.0+ => Use 1.5.0 (MVS)
  5. You write --lib foolib@2 --lib barlib => error (or link both??)
  6. You write --lib foolib@1 --lib barlib => Use 1.5.0 (MVS)

@pierrec
Copy link
Contributor

pierrec commented Jul 8, 2023

I like this actually. Package managers are a nightmare. Thanks for the explanations.

@lerno lerno added this to the First release (v1.0) milestone Jul 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion needed This feature needs discussion to iron out details Enhancement Request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants