It was broken because fake-warehouse and test-package-server were
incompatible. In order to actually use the published packages, we had
to sync test-package-server into the local warehouse. But as soon as we
did that, the latest release became some other random release.
In any case, the semantics tested here have changed twice since 0.9.0!
In 0.9.0.1 we changed it from "ask for any RC means get any RC" to
"don't get any RCs that aren't explicitly anticipated". And in 1.1
we're changing it to "minimize unanticipated RCs".
Manually running through the equivalent of this test, most of it works
except for the last line; `meteor update` will not take you from one RC
to the next, due to minimizing unanticipated RCs. That's probably fine
though.
While we're at it, make it much more clear that warehouse and
test-package-server don't work together.
Undocumented flag. This is one of those cases that is rare but may
come up, because `meteor list` runs the version solver (and writes
.meteor/versions). For example, it may come up if you run `meteor
list` with PACKAGE_DIRS and then without (or vice versa). You'll
get a message that says to pass --allow-incompatible-update, so we
must support it.
When you `meteor publish` a package (not from an app), a
ProjectContext is created that gets the Version Solver
"previousSolution" from the .versions file in the project directory.
From the point of view of the Version Solver, the package itself is
a root dependency, so if the version changes from last time, you
may be asked to pass --allow-incompatible-update! That isn't right.
However, the ProjectContext created by `meteor publish` doesn't know
it is created for a particular package. But it does have the package
marked as "explicitly added." So for now, the simplest thing to do
is to alter the input to the Version Solver based on the value of
explicitlyAddedLocalPackageDirs.
Oh, another wrinkle here is that we don't actually know the name of
the package we're publishing when we create the PackageContext, so it
can't be an option.
Example of a failing self-test that now passes:
'packages with organizations'
It's unfortunate that this change is in `compiler.compile`. It's
actually unfortunate that we only catch this during publish-for-arch.
But it seems too much to disallow all packages published with colons
even if they don't have binary dependencies since a lot of old
packages were created with our command-line tool that created
filenames with colons in them.
We were incorrectly always assuming that Meteor is running
by not actually trying to connect to the port that the
MONGO-PORT file reports Mongo is listening to.
The problem is that that file isn't cleared when Meteor
quits or crashes.
Fixes https://github.com/meteor/windows-preview/issues/138
In particular: `create`, `test-packages`, `rebuild`, `publish`,
`publish-for-arch`, `admin run-upgrader`
Add it to the help text for `publish`, and simply force the flag to
true in `create`. Other commands get it as an undocumented flag
in case the version solver tells you to pass it in.
The fix is actually in https://github.com/npm/fstream/pull/42,
but now we also remove our explicit path length check
that used to throw an error instead of silently losing files.
This commit also adds a self-test to test the entire flow
through `files.createTarball` and `files.extractTarGz`.
