Should external clients depend on runtime:1.0.0, runtime:latest, or runtime:1+?

[pingpongboss]

I would like to discuss the merits of multiple dependency versioning schemes in the context of external clients. All 3 platforms use different package managers, but most likely we all have the same options:

1. Named version - runtime:1.0.0
2. Latest (stable) version - runtime:latest
3. Latest for a major version - runtime:1.+

Here are the pros and cons of each.

1. Named version - runtime:1.0.0

Pros: Updates to runtime cannot break client. Builds are predictable and repeatable.

Cons: Some clients may miss updates. More likely to be running an older unsupported version. README and other documentation constantly needs to be updated.

2. Latest (stable) version - runtime:latest

Pros: Client will never miss an update. Always on latest. README and other documentation never needs to be updated.

Cons: Major version updates to runtime will break clients. Builds are unpredictable and unrepeatable.

3. Latest for a major version - runtime:1.+

Pros: Major version updates to runtime cannot break clients. Client will not miss minor and patch updates. README and other documentation occasionally needs to be updated.

Cons: Some clients may miss updates. Some clients may be running an older unsupported major version build. Builds are unpredictable and unrepeatable. Android package manager warns against this for all clients.

WDYT? I originally leaned towards option 3, but now I am split between option 1 and 3. Also it's worth thinking about what is idiomatic on each platform? For example: Linux .deb packages depend on the latest, but recent Linux container formats depend on a specific version. Android gradle dependencies tend to declare specific versions rather than latest or 1+. pod/npm?

[appsforartists]

For npm, I'm in the habit of depending on specific version numbers. Otherwise, when someone in your dependency spaghetti fucks up semver and publishes a breaking change with a non-breaking version number, your build is broken and it's nearly-impossible to know what broke or how to fix it.

[jverkoey]

My gut's saying that this is a domain in which we should educate but not provide specific recommendations.

[jverkoey]

Sorry, I meant to say we shouldn't provide general recommendations. Hyper-specific recommendations may be helpful.

[jverkoey]

For example: "I never want to be broken unexpectedly: track a specific major version"

[randallli]

forgot that i can't respond in email to these. what I said via phone:

Isn't this feature the responsibility of the dependency system? When using cocoapods I would pull in a framework with unspecified version. This means I get the latest version. Including breaking changes. If the upstream lib never breaks me I don't care. Once they do I take a measure of level of effort to fix and if it's to much to fix on the spot then I start specifying the major version. If that isn't enough then I keep specifying.
What I'm describing isn't a feature of any lib. It is how the dependency system works. The libraries themselves don't have to concern themselves with latest stable as long as they follow semantic versioning. Is this not the case with Android s dependency system?
Btw cocoapods has a prospect.lock file which holds the actual value used in the current build. This allows one to specify the exact version of all dependencies if needed.

What I was trying to say is summed up pretty nicely on the cocoapods guides about Specifying pod version
I see this as the responsibility of the dependency system and not the library.

[appsforartists]

Do your dependencies have dependencies? That's the problem with npm - not only can you upgrade your dependencies but you can upgrade their dependencies. Makes it really hard to reason about what's installed unless you do it all manually (by locking down versions as much as possible).

[pingpongboss]

Thanks for the inputs everyone. I've gone ahead and drafted a versioning guidance for Android based on what everyone said http://codereview.cc/D1223

In general, I suggest new projects try to depend on latest runtime:+. Later on, depend on a specific version runtime:1.0.0 for more predictable builds and stability. I also give the option of depending on a range runtime:1.+.

I also give guidance on contributors who want to depend on local changes runtime:local. It's not perfect yet (devs cannot push a runtime:local dependency to Github, so they have to ignore it somehow?), but it's not within the scope of this issue.