Deno: Consider "release" branch of std

[kitsonk]

We currently committed code to master for std to be compatible with the version of the cli in master, and that flushed out a whole set of people complaining about the breaking changes and code not running. People are either ignoring the warning message, not understanding what it means, or depending on code that depends on master. All which lead to 😠 😭 😖.

Maybe we should introduce a release branch for the purposes of std which is created at the same time as the cli release, and point https://deno.land/std/ at that branch by default instead of master. We can then eliminate the warning code in the cli as well. I believe it is reasonable to expect https://deno.land/std/ to be compatible with the current release of the cli, even though people should still depend on specific versions as a matter of best practice.

[lucacasonato]

Just a heads up: importing mutable refs (like branches) through /x will be removed soon as part of the registry refactor. Only released versions will be accessible. That should solve this issue once and for all. Unversioned URLs will either be removed, or will redirect to the latest released version. I am personally for removal.

(/std also uses /x)

[ry]

Unversioned URLs will either be removed, or will redirect to the latest released version

latest released version seems more useful

[kitsonk]

I think there is an expectation of a "bare" URL pointing to something useful, so I would be 👍 for latest released version, but don't forget to use Deno as an example, where there is a pattern to the tags that needs to be considered to figure out the latest "release" of cli versus std.

[caspervonb]

Latest tag seems better than just having it point to nothing.

[SyrupThinker]

Making release the new default branch just extends the cycle when modules break.
With unversioned std imports every breaking change in std, whether intentional (2.0 etc) or not, will break part of the ecosystem.
With versioned ones it will keep working as long as the runtime supports what is used, for example pure JS modules that have just been (re)moved in later releases.

[nayeemrmn]

We can then eliminate the warning code in the cli as well. I believe it is reasonable to expect https://deno.land/std/ to be compatible with the current release of the cli, even though people should still depend on specific versions as a matter of best practice.

At the very least we need to keep the warning for any rangeless implicit version resolution.

Keep in mind that imports like this are NOT simply opt-in. I have no control of the import URLs used for my transitive dependencies other than unstable import maps. My lock file check can _will_ just suddenly break at some point, unless everything in my dependency graph is following this best practice. It's much better if I've been seeing a warning leading up to this so I can choose (or report bugs to) my dependencies better.

But really, if locked deps seem more like a necessary practice than a best practice, there's no reason to support mutably implicit tags in our registry. Are you sure we're not just masking the difficulty of looking up the latest version of a module?

[lucacasonato]

I think this was mostly fixed by the registry refactor.

[kitsonk]

It solves enough of this problem to close the issue, certainly.