What happened to beta.13, beta.14, and beta.15? All unfortunately suffered
from problems that made it either impossible or unwise to upgrade to those
versions.
- We don't want to do a bunch of parsing *per comparison* when sorting
a list of package version strings. package-version-parser's `compare`
(and server's `compare`, which it uses) both accept either a string
or a parsed record. By parsing explicitly with memoization, we avoid
a super-linear blow-up in the amount of parsing. This'll save someone
half a second, at least.
- Adjust profiling hooks and messages
- Expose `Profile` to isopackets
The beta released with this commit (modules-beta.6) included everything on
the release-1.3 branch up to bdf64da339
("Avoid circular package.json resolution chains.").
Unfortunately, additional commits were pushed to the branch before this
commit was pushed, so the release tag release/METEOR@1.3-modules-beta.6
does not correspond to any commit in the branch history.
Rather than attempting to rewrite the branch history, I decided to amend
this commit with this explanation before pushing it.
To see exactly what was released with the sixth beta:
git fetch --tags
git log release/METEOR@1.3-modules-beta.6
Tried to get everything to an rc.0 of the very latest version,
which required some research in some cases about the published
versions. For example, some packages had version histories like:
```
...
1.0.3-winr.2 January 20th, 2015
1.0.3-winr.3 February 24th, 2015 installed
1.0.3 March 17th, 2015 installed
1.0.4-anubhav.0 August 6th, 2015
1.0.4-plugins.0 July 22nd, 2015
1.0.5-galaxy.0 July 17th, 2015
```
In this case, I would bump the version from `1.0.4-plugins.0`
to `1.0.5-rc.0`, skipping `1.0.4`.
This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
It used to create a directory with an underscore instead of a colon
Now, it just removes the prefix.
In cases where the name of the package has more than one colon or starts or ends
witha colon, we report an error.
In particular, ban leading `-`, trailing `.`, and `..` anywhere.
This backport commit drops the changes to constraint-solver and adds a
History.md note.
Verified manually that `meteor update asdf.` displays an error,
not a stack trace.
Include the offending name in all error messages (as we do for
invalid versions).
In the return value, `name` has been changed to `package`,
and `vConstraint` is now `versionConstraint`.
`constraint.package` is better than `constraint.name`, where
`constraint` is a PackageConstraint. It's also more consistent
with functions like parsePackageAtVersion which return an object
like `{package, version}`.
`vConstraint` was too cryptic.
Changes were discussed with Glasser in a code review.
Troposphere does not call parseConstraint or work with constraint
objects, so it doesn't need to change.
This is a breaking change to the package-version-parser API (or one
method of it, at least), but it is considered an internal API so we
are not worrying too much about it.
