search

dxos / gravity

System testing frameworks.
GNU Affero General Public License v3.0
1 stars 1 forks source link

DEP1 - package naming and cross-repo integration #33

Open dmaretskyi opened 3 years ago

dmaretskyi commented 3 years ago

Each of the development branches outlined in DEP0 publishes under a separate namespace:

Packages can only have dependencies on other packages with the stability level equal to theirs or higher. Example: @dxos-dev/sdk can depend on @dxos-dev/object-model, @dxos-beta/object-model or @dxos/object-model, but not @dxos-nightly/object-model.

We develop a set of tooling to promote packages across boundaries and verify the integrity of dependencies.

dboreham commented 3 years ago

We said not to use the word "nightly". Also not to use "canary"...

dmaretskyi commented 3 years ago

How would we name the releases published from master?

dboreham commented 3 years ago

I think this is about the following problem:

Given a conceptual release promotion structure (dev -> beta -> release) , how do we arrange that cross-repo dependencies are resolved such that for any given package, its dependencies are resolved from the "appropriate" promotion level in those dependency packages. The thing is : there's no hard and fast requirement that for example "dev teamwork" should depend on "dev echo". In fact quite likely "dev teamwork" might depend on "release echo".

This problem seems only solvable in an ad hoc manner : developers have to curate the names of and (major) versions of dependencies. There is no automated dependency selection mechanism that can predict the correct outcome.

dboreham commented 3 years ago

But there's a second problem:

Given some new feature effort that transcends a single repo (e.g. "add wallet support to halo, teamwork, bots), how do we make the set of dependencies and "rolled up" packages like teamwork such that they include the wallet-feature branch version of everything?

The best proposed solution (by some definition of best) I've heard for this is to do what we did with the "-experimental" packages : arrange to have different package names for these branched dependencies : halo-wallet, echo-wallet, botkit-wallet etc.

dboreham commented 3 years ago

Third problem:

Given a promotion hierarchy with corresponding branches and published npm package versions, how do we keep track of which version corresponds to what promotion level? e.g. if I want the latest "beta" version of halo, how do I know which semver to specify to get that?

Answer may be that his is what "preid" strings are for: you can inspect the history of npm for a given package and see that there's a version 2.3.4-beta.11 that's newer than all other "beta" preid versions.

dboreham commented 3 years ago

Addressing these problems is postponed for later. For now we will live with the DEP0 scheme.