I want to depend on a well-defined versioning scheme for the Polywrap toolchain

[dOrgJelli]

Currently all packages published to the @polywrap npm organization use the same version, defined in the VERSION file.

This is not very ideal when we start using proper MAJOR.MINOR.PATCH semantic versioning. For example, if we make a breaking change to the CLI, the underlying packages (client, core, etc) should not be effected.

We should come up with a more sophisticated way of versioning the various parts of the project, allowing developers to easily consume packages, and not need to update packages needlessly when nothing within them has not changed.

Tasks

• [ ] Define a versioning scheme for all Polywrap packages
• [ ] Implement the new versioning scheme within the CI/CD workflows

[dOrgJelli]

This has been discussed, and will be done post-origin release, but before we get to 1.0

[dOrgJelli]

Proposed Implementation

Initial Rules

1. If a breaking change occurs in a package, bump major.x.x of that package
2. If a feature has been added in a package, bump x.minor.x of that package
3. If a fix has been made to a package, bump x.x.patch of that package
4. All dependencies should be pinned to major.minor.x, but may accept patch upgrades from all @polywrap packages.
5. All major & minor versions bumps should be applied to all packages down-stream.
6. major version bumps should be applied downstream immediately.
7. minor version bumps can be applied on an as-need basis.

Dev Ops

Some thought should be put into how we manage our dev ops around this process. I have a few ideas (config files in the root of the monorepo, devops scripts, etc), but will outline later.

Extra

All interfaces will only need to be versioned by major and minor version numbers, because there is no such thing as a patch of an interface since there is no underlying implementation. - This is good because when users are defining manifests, they can specify the version using only 2 numbers (ex: wrap.info -> format: 1.2). Super simple for the user.

[nerfZael]

So far it's been pretty convenient for users of @polywrap packages to bump all packages when they bump one. It's easier to know which package is compatible with which. I think the proposed changes are a bit early to be applied at our current stage. When most users stop constantly updating to the latest version of all packages but want a specific package updated, then that will be a good time to apply these changes.

A good next step, IMO, would be to have the proposed process per repo (integrations repo might be an exception). We should also consider starting to separate some packages into their own repos:

• CLI
• React (into integrations repo)
• Plugins (into integrations repo)
• Client (maybe)

Lastly, I don't think down-stream changes are always required even in major releases.