The only way I currently found is
curl https://install.meteor.com/\?release\=3.0-beta.0 | sh
however this removes all my current meteor installation before installing the new one.meteor point to 3.0-beta.0 ?
Updating inside a project keeps the global at 2.14
1 Like
So I also found, that after the shell script install, my home directory ~/.meteor is empty, although the script said
Edit: that was not true. However, the below is true:
If I enter meteor or any of it’s command it immediately tries to install 2.14.
Edit: after it has installed 2.14 and I enter meteor --version in any non-project folder it now shows 2.14 as global Meteor version.
So it turned out I didn’t need the global Meteor 3.0. My real intend was to publish with 3.0 as top-level, which I thought would be solved by setting global meteor to 3.0.
Actually I got some hints from @zodern that I can publish packages using --release option, which is not documented yet. By doing so I could resolve all top-level conflicts.
Related PR and Issue:
meteor:release-3.0 ← meteor:feature/describe-top-level-reason
opened 06:25PM - 21 Dec 23 UTC
When there are conflicts in the version constraints for a package, Meteor lists … all of the constraints along with the path. Sometimes the path is simply `top level`. The meaning of `top level` doesn't seem to be common knowledge anymore (if it ever was), so this PR adds an explanation for why the package is top level (it is either a local package, or the constraint is from the release).
I haven't tested the code for top level packages from a release since when running Meteor locally every core package is a local package. I thought the meteor-tool might have a way to test this, but I didn't find one.
```
=> Errors while adding packages:
While selecting package versions:
error: Conflict: Constraint caching-html-compiler@2.0.0-alpha300.16 is not satisfied by caching-html-compiler 1.2.1.
Constraints on package "caching-html-compiler":
* caching-html-compiler@=1.2.1 <- top level (is local package)
* caching-html-compiler@2.0.0-alpha300.16 <- static-html 1.3.3-alpha300.19
Conflict: Constraint templating-tools@2.0.0-alpha300.16 is not satisfied by templating-tools 1.2.2.
Constraints on package "templating-tools":
* templating-tools@=1.2.2 <- top level (is local package)
* templating-tools@2.0.0-alpha300.16 <- static-html 1.3.3-alpha300.19
* templating-tools@1.2.1 <- caching-html-compiler 1.2.1 <- static-html 1.3.3-alpha300.19
Conflict: Constraint caching-compiler@1.2.2 is not satisfied by caching-compiler 2.0.0-alpha300.19.
Constraints on package "caching-compiler":
* caching-compiler@=2.0.0-alpha300.19 <- top level (is local package)
* caching-compiler@1.2.2 <- caching-html-compiler 1.2.1 <- static-html 1.3.3-alpha300.19
```
opened 11:16PM - 08 Jan 24 UTC
Using Meteor 2.14 I can enter `meteor publish --help` which gives the following … documentation:
```
Usage: meteor publish [--create]
meteor publish --update
Publishes a new version of a local package to the package server. Must be run
from the directory containing the package. Reads the package.js file for version
information, builds the package and sends both the package source and the built
version of the package to the package server.
This will create at most one build of the package. If the package has an
OS-dependent binary component, publishing will only register metadata about the
package. The binary component will be compiled when it is installed into an
application with `meteor add`. To pre-build a package for a particular platform,
use the `meteor publish-for-arch` command.
This will mark you as the only maintainer of the package. You can use
'meteor admin maintainers' to change package maintainers. For more information
about admin commands, run 'meteor help admin'.
Change the metadata for a given version of a package by running with the
--update flag. That will set the git url, version summary, longform description
and documentation in the database to their new values. You can use 'meteor show'
to preview the results.
Pass --create to create a new package.
Options:
--create publish a new package
--update changed metadata of a previously published version
--allow-incompatible-update Allow packages in your project to be upgraded or
downgraded to versions that are potentially incompatible with the
current versions, if required to satisfy all package version
constraints.
--no-lint don't run linters on the published package and its local
dependencies before publishing
```
However, I didn't know that I can actually use `--release` here in order to resolve "top-level" version conflicts, which was recently a big blocker when attempting to publish packages for 3.0 beta.
This option should be added to the help and maybe also to the migration docs. Might be crucial for people who struggle with migrating packages.
1 Like