Duplication was introduced at merge c78e04645d. Commit
ccc2526 (right-hand side of merge) moved this code from the bottom to
the middle. Commit 21411b4 added a newline at the end of the file,
which made this a conflicted merge; the merge conflict was not resolved
properly.
Fixes#3208.
It parses “=1.0.0” but not “=1.0.0 || 2.0.0”. It shouldn’t be a public thing (and is never used publicly).
There should be only two things: versions and constraints. A value that can legally be “=1.0.0” is not a version, it is a constraint (and yet we still call it versionString in a few places). A value that can be “=1.0.0” but not “1.0.0 || 2.0.0” is not a constraint; it is at best a rare creature called something like a “simple constraint.” We may expand the syntax of constraints again in the future, and we can’t have N things called a “constraint.”
It was only used in one place in resolver.js. If the semantics of constraints are that buildIDs are ignored, that should be implemented when interpreting a constraint, not parsing it. We don’t use buildIDs ourselves anymore, so it’s rather theoretical, but we’ve always stripped them out of constraint strings so it’s not even clear why we allow them at all — ie. why we are willing to parse “=1.0.0+foo” as a valid constraint and then throw away the “+foo”.
Bonus: One less place where we conflate two different options objects (utils.parseConstraint and PV.parseConstraint).
Despite the name “package-version-parser,” PVP didn’t really provide a way to parse a package version. With this change, if you want to get the minor version of “1.2.3_4”, for example, you can just write `PV.parse(“1.2.3_4”).minor`. This simplifies the internals of PVP as well.
When you parse a version, you now get an instance of PackageVersion with a documented set of fields.
Also, make PVP work on the client. When called directly from the tool, semver is loaded the same way as before. When PVP is used as a package, it uses a copy of semver v4.1.0 kept inside the package.
This change is intended to be 100% behavior-preserving.
The session variable didn't mean "show an issue", it meant "allow an
issue, if one exists, to be shown". Describing it as "ignore an issue
that exists" seems more direct to me.
Addresses #3031.
This commit moves parent pid process from the webapp package to the boot
script. This means that daemonized apps without webapp will also exit
when the runner exits, if run from the runner. (For example, several
self-tests such as 'autoupdate' no longer leak node processes.) This is
controlled via the $METEOR_PARENT_PID environment variable instead of
from command line arguments, in order to make fewer assumptions about
how Meteor apps process arguments.
This also drops the old --keepalive support (which already has stopped
being used by the dev mode runner or any MDG deployment platforms).
Neither --parent-pid nor --keepalive were documented beforehand, and
--keepalive was already deprecated before 1.0.
These flags used to also incidentally trigger printing the LISTENING
line; this is now controlled by $METEOR_PRINT_ON_LISTEN.
Fixes#3315.
Specifically, this means that errors during publish-release
--from-checkout can include the package name, since buildmessage errors
only mention the innermost job name. (It's more important for
publish-release's errors to include the package name than for publish,
since for publish you presumably know what package you're publishing
anyway.)
Fixes#3323.
It was already set for most common commands, and was unnecessarily not
set for others.
The following commands are remaining "pretty: false":
- Commands that just print machine-parseable text: --version, --arch,
admin members (without --add or --remove), mongo --url,
authorized (without --add or --remove), whoami, list-organizations, list-sites
- Commands that just switch over to another codebase's interactive
command: mongo without --url, admin get-machine, shell
The following commands used to be implicitly "pretty: false" and now
will be pretty:
- A bunch of troposphere admin commands: set-banners, recommend-release,
change-homepage, set-unmigrated, set-latest-readme
- A few accounts/deploy related commands: logs, claim, login, logout
- remove-platform, reset, self-test
- admin maintainers (which unlike admin members and authorized prints an
English header before the user list; maybe this is a mistake)
It might make sense in the future to further separate "pretty means can
show progress bars if the output is a TTY" from "pretty means can use
chalk styling and unicode bullets".
Fixes#3162.
Note that "backport" here doesn't just mean "patch release"; it means
"patch release to a release that was not the newest release" (ie, an
out-of-order entry in history)
Rather than waiting until process end.
Also, ensure that simultaneous calls to files.rm_recursive (possible now
that they can yield) can't throw ENOENT.
Fixes#3324.
The missing JSON.parse meant that we were always calling new Date on a
string that started with a quotation mark and getting an invalid date
object, which caused shouldShowBanner to always return false if a banner
had ever been previously printed for that release. Oops. Bug introduced
in 1.0.2.
(At least the non-custom banner still prints.)
Fixes#3353.
Because that's where the SIGUSR2 handler is.
Arguably this should be some more abstract interface where packages can
say "I have a handler for client refresh", but whatever.
Fixes#3365.
Instead, increase polling interval for that file/dir to 500ms from 5s.
Fixes#3336.
The most common case where this was occuring is when you're on Linux and
your inotify max_user_watches is too low. A wiki page will explain how
to increase this. In debug mode, a message will tell you to go to the
wiki page if you hit the limit (we may later expose this message by
default, but it is part of the new user experience).
Conflicts:
meteor
tools/safe-pathwatcher.js
Instead, increase polling interval for that file/dir to 500ms from 5s.
Fixes#3336.
The most common case where this was occuring is when you're on Linux and
your inotify max_user_watches is too low. A wiki page will explain how
to increase this. In debug mode, a message will tell you to go to the
wiki page if you hit the limit (we may later expose this message by
default, but it is part of the new user experience).
