What would it mean if a package is "private"? Is it just a hit to the user that they probably won't want to use it?

What is the use-case for private packages? Something shared between two other packages? If so, could it not just be in one of the packages' src directory, and being used by the other library?

Use case:
Several packages X, Y and Z have code in common, to reduce dart2js output size (in case a user uses several of these packages) the code should be de-duplicated. The way to achieve that is to make another package B, on which the other packages depend. This package B is only shared across X, Y and Z. We do not want users/other people to use B.

B might get rapid major version upgrades, but since X, Y and Z use it only internally, they just use a new major version of B and update their patch version. As soon as other packages depend on B, users might run fast into version constraint conflicts, because B is bumping major versions quickly.

=> Since B was intended to be shared across X, Y and Z, there is no need that B shows up in search results on pub.dartlang.org or in the editor. The only developers who need to know it exists, are the authors of X, Y and Z.

B might get rapid major version upgrades, but since X, Y and Z use it only internally, they just use a new major version of B and update their patch version.

My understanding is that B won't need to rev its major version as often because it's private.

For example, in a normal package, if you add a required parameter to a method, that's a breaking change because some other package could be using that. In a private package, if you know that the actual packages you control that are using the private package won't be broken by that change, you can consider it non-breaking and don't have to rev the major version.

there is no need that B shows up in search results on pub.dartlang.org or in the editor. The only developers who need to know it exists, are the authors of X, Y and Z.

Clarification here. Users do need to know it exists and should be able to step into it in the debugger, go to definition, etc. This code is part of their application after all. It's just that they should be discouraged from directly depending on it because its API doesn't follow the same semver constraints as normal packages.

My understanding is that B won't need to rev its major version as often because it's private.
For example, in a normal package, if you add a required parameter to a method, that's a breaking
change because some other package could be using that. In a private package, if you know that the
actual packages you control that are using the private package won't be broken by that change, you
can consider it non-breaking and don't have to rev the major version.

First: "if you know that" -- you obviously cannot know who uses a private package. Packages D, E and F could depend on the private package as well -- how would you like to prevent that from happening?

Second: We give packages a semantic version number. Following your logic, private packages are not following the semantic version numbering in this case. We would introduce two different version semantics? Seems pretty fragile to me.
[And considering the fact that our current definition of "semantic backwards compatible changes" is a gray-area as was recently proofed again with the interface discussions -- it would hurt adding another "private package semantics"]

The thing we would like to prevent is that normal developers/users discover a private package (=> therefore we do not want to have search results in the editor / on pub.dartlang.org for private packages). This will prevent normal developers/users

• be confused when searching for a package (e.g. a private package with http in it's name should not show up when searching for a http package)
• to depend/use a private package

It is therefore only an implementation detail of X, Y and Z. It will not cause version constraint conflicts if no other packages depend on it (which is the intent, but not enforced).

Clarification here. ...

I don't think this clarification is necessary. It's obvious, that users can see all code -- including SDK internals. This doesn't mean people should know/care about the SDK internals, does it?

First: "if you know that" -- you obviously cannot know who uses a private package. Packages D, E and F could depend on the private package as well -- how would you like to prevent that from happening?

There's no need to prevent this from happening. It's clear that other users aren't supposed to depend on this package, so it's under no obligation to maintain compatibility for them.

Second: We give packages a semantic version number. Following your logic, private packages are not following the semantic version numbering in this case. We would introduce two different version semantics? Seems pretty fragile to me.

It's up to the authors of the package what versioning semantics they use. Since it's a private package, I don't see how it's anyone's problem but theirs if they decide not to use semantic versioning.

It's up to the authors of the package what versioning semantics they use.

I got the impression that the version numbers in pubspec.yaml were following the semver spec with our definitions of "breaking change".

But maybe pub is only concerned about the syntax of these version numbers, the ordering of versions and constraint solving and the semantics are just rough guidelines we give to users. If that is the case, then you are correct.

I really didn't want to get into a discussion here. You're the authors of pub, the feature request is on your plate.

Set owner to @munificent.
Added Started label.

The package validator when you publish will no longer prohibit a package whose name starts with "_".

Added Fixed label.

This issue has been moved to dart-lang/pub#1098.