I'd love to see this become the gold standard of JSR packaging, esp multi-package libraries, and ideally see all scripts/tooling/cross-runtime testing used by the lib become a first class set of modules within the library itself, so that other authors can model their libraries on @std, and benefit from its tooling. I want you follow your model closely in my own library and would be more than happy to contribute to generic tooling and @std itself.

That'd be great! Improving test coverage is one of the valuable contributions that can be made right now. If you're willing and able, please let us know which package(s) you'd like to look at in #3713. I'll keep you in mind when tooling is needed.

I agree that it makes sense to stabilise the different parts of the standard library at different points in time. However, it is rather annoying to have independent versions for each module.

Currently, we're moving towards a myriad of independent modules, and it adds a fair bit of accidental complexity to let the combinations of (#modules * #versions) explode like that.

I believe that it is a good idea to version the modules independently for the transitional period until almost everything is stable. After that, it would be best to sync up the versions again so that we can return to having The Standard Library again.

If all packages share a common, synced version, how should the versions of other packages be affected if a single package needs a release?

so that we can return to having The Standard Library again.

I'm unsure what you mean here. Can you please clarify?

If all packages share a common, synced version, how should the versions of other packages be affected if a single package needs a release?

If there's only a single version, then this version needs to be incremented for every single package. This is fine because a stable standard library should not require a lot of fast fixes, and it is alright if the features are released at a much slower pace. (1-4 times a year maybe?)

so that we can return to having The Standard Library again.

I'm unsure what you mean here. Can you please clarify?

The JavaScript ecosystem is missing a set of useful APIs that are reliable, trustworthy, omnipresent, simple, mature. The modules in this project could fill this exact gap. If they're not aiming to reinvent lodash-but-Deno, but rather trying to be sort of a gold standard (that's what I was trying to imply by calling it “The Standard Library”) then it is important to perceive this as a unit.

So basically, the effect of having independent versions is that std is now scattered into a million pieces, and there's no longer “the thing.”

IMHO, the point is that it's a "Library", in this case, a loose collection of packages, which in turn is a collection of modules, it isn't one "thing", ie. it's not "The Standard Package".

Whilst it may seem superficially nice to align the version of each of these packages, the versions will lose all semantic meaning if kept abitrarily in sync. One package version shouldn't be bumped to line up with another if that package hasn't had similar semantic changes, it's just misleading.

For example, in a hypothetical situtation, if I'm working on a pure CLI program I may not care that @std/http has changes, and so unnecessary version bumps to @std/cli would just be annoying.

What I think we definitely need though is for JSR to show the latest versions for each package within a scope... jsr-io/jsr#421

Whilst it may seem superficially nice to align the version of each of these packages, the versions will lose all semantic meaning if kept abitrarily in sync. One package version shouldn't be bumped to line up with another if that package hasn't had similar semantic changes, it's just misleading.

For example, in a hypothetical situtation, if I'm working on a pure CLI program I may not care that @std/http has changes, and so unnecessary version bumps to @std/cli would just be annoying.

I agree, and that's why I was saying that if versions are to be synced up, then the frequent releases have to stop. If you always only get a new standard lib twice a year, then you don't really run into the above problem. The first reason for this is that most packages will have changes of some sort, and the other reason is that even if there's a new release without changes to the parts you use, then this happens so rarely that it doesn't matter much.

The current way of having to do bookkeeping of a large number of modules, each with its own version and stability status, is really annoying, too.

I agree with that having the version for the packages in STD in sync would be better for a coherent library, however I also see the argument with it not bringing any benefit in bumping a version without any changes. I am thus not sure if strictly following semantic versioning is the best option for the standard library.

I could see an alternative versioning scheme instead that could potentially work better:

• patch: any feats or fixes, this version could be updated on a package basis whenever needed and would not be library wide
• minor: released periodically 1-4 times a year, this would be updated for all packages regardless of updates made to the package
• major: would signify a major change in the codebase or direction for the library, would be very seldom or potentially never

patch versions would not introduce breaking changes, but minor versions could.

When using packages from the STD, it could be recommended to use ~ for the version range, and manually bump minor versions when needed.

Yes, we now recommend the users should use version range dependency like @oak/oak@^16.0.0 or @std/path@^0.224.0. These module specifiers will automatically get fixes and new features, if you run the program with --reload option.

Also deno now has deno add <mod> command. This command automatically looks up the latest version of the given jsr package, and add them to deno.json with range dependency set up appropriately. So you even don't need to manage the version number by yourself.

When using packages from the STD, it could be recommended to use ~ for the version range, and manually bump minor versions when needed.

We rather recommend caret ^ range, instead of tilde ~. The caret ^ range includes minor and patch upgrades for >1 versions, and it includes patch upgrades for 0.x versions. This means you'll get fixes and new features automatically when the upstream is upgraded.

@halvardssm

I could see an alternative versioning scheme instead that could potentially work better:
...
patch versions would not introduce breaking changes, but minor versions could.

This sounds like a significant deviation from semver spec (semver explicitly prohibits the breaking changes in minor upgrades https://semver.org/#summary). I think we should rather follow the semver instead of introducing our own convention.

So you even don't need to manage the version number by yourself.

Maybe not when adding a new module for the first time, but:

1. you need to update your dependencies at some point, and then you do actually have to figure out the current versions for every module, no matter if ^ did this automatically before
2. there is no deno update-all-my-jsr-dependencies-to-latest subcommand so people will indeed have to look up the versions manually, or employ some sort of script or other form of automation (renovate etc) that does this
3. every other major language with a standard library has a single version for it (Rust, Go, even Java and C#, you name it) so making such a mess with many independent versions is breaking expectations

1. you need to update your dependencies at some point, and then you do actually have to figure out the current versions for every module, no matter if ^ did this automatically before

Someone did make a script on JSR to update their dependencies. I don't remember what it was called though.

2. there is no deno update-all-my-jsr-dependencies-to-latest subcommand so people will indeed have to look up the versions manually, or employ some sort of script or other form of automation (renovate etc) that does this

A deno dependency-update would be nice. Maybe someone should suggest that in the Deno repo.

3. every other major language with a standard library has a single version for it (Rust, Go, even Java and C#, you name it) so making such a mess with many independent versions is breaking expectations

Peoples expectations isn't a reason to do something, and everyone else doing something one way doesn't mean Deno should as well. Tradition for the sake of tradition is a bad reason.

1. you need to update your dependencies at some point, and then you do actually have to figure out the current versions for every module, no matter if ^ did this automatically before

Someone did make a script on JSR to update their dependencies. I don't remember what it was called though.

There will be a plethora of such scripts if we go ahead with this. Even Node tooling has evolved to update Deno deps: https://www.npmjs.com/package/npm-check-updates

2. there is no deno update-all-my-jsr-dependencies-to-latest subcommand so people will indeed have to look up the versions manually, or employ some sort of script or other form of automation (renovate etc) that does this

A deno dependency-update would be nice. Maybe someone should suggest that in the Deno repo.

It would be nice, but for other reasons. The point here is “look, the current situation is so complex that we even need new tooling, this is done needlessly” and I hope your takeaway from this isn't “wohoo, we created a superfluous problem, let's solve it by building new tooling!”

3. every other major language with a standard library has a single version for it (Rust, Go, even Java and C#, you name it) so making such a mess with many independent versions is breaking expectations

Peoples expectations isn't a reason to do something, and everyone else doing something one way doesn't mean Deno should as well.

In fact, building intuitive stuff is a pretty good goal. The opposite of this would be to make things obscure and unexpected, and that surely isn't what we want.

Tradition for the sake of tradition is a bad reason.

You seem to have misunderstood. This is completely unrelated to tradition. The point was not “it's always been this way, let's keep it that way” (then we'd all be using Node) but rather that the rest of the industry isn't stupid. Whenever people innovate a standard library, they conclude that having a single version is good. Doing things differently just for the sake of doing them differently isn't a good approach, either. Instead, we should take a look at why everybody else does it a certain way, and not neglect their findings just because it could be “tradition.”

If we find out that they're indeed all stupid and that having 37+ independent versions is much more simple and intuitive than having 1 version, then sure, we can go on like this :)

@KnorpelSenf
I think we are still open to the idea of single versioned standard library in some form (such as #4327 . Let's keep this discussion there), but right now we need to split it into pieces to make the stabilization process going forward in a reasonable manner. (See also https://deno.com/blog/std-on-jsr#independent-versioning-for-each-standard-library-package )

Also the Deno community still keeps requesting the breaking changes to the standard library constantly. If we stabilize the entire standard library with a single version, then we probably stop accepting any of such request because the impact of such change would be too large. I personally don't think that situation meets the expectation of the Deno community.

@kt3k awesome, I wasn't aware of #4327, thanks for the reference.

I completely agree that having independent versions is the most reasonable approach as long as things are not stable yet. I tried to make this clear in my initial post already, no disagreement there :)

I’m also completely agreeing with @kt3k. I’m just worried if not all of the Deno team agrees with that: #4327 (comment)

This work is now complete. PTAL at "Excluded Packages" for continued stabilization work that was not part of the main phase of stabilization. Thank you to all who helped!