After upgrading to 1.4.1.2 my tiny toy leaderboard app stopped starting. The debug run gets stuck after “Starting MongoDB”. Webstorm support told me to try “meteor reset”. When I do it, I get:
Downloading meteor-tool@1.4.1_1… [=== ] 13% 30.1s
Does this mean that meteor’s backward compatibility is implemented:
by downloading the version found in the .meteor/local/release file
unzipping it
installing it somewhere on the client in addition to the latest release that was manually installed?
Could someone explain to me how this works, or send me a pointer to a clear description of this?
BWT it in fact does not work as unzipping gets into an infinite loop:
Extracting meteor-tool@1.4.1_1… \
So now my app does not start with 1.4.1.2 and installing 1.4.1_1 with which it was starting seems impossible due to this unzipping loop bug.
Is there a workaround this?
Should I have sent this message to Github or StackOverflow instead of here?
I can’t remember the last time I did a meteor update in less than an hour (the good old days when it took minutes). Right now I’m waiting on Extracting meteor-tool@1.4.2-beta.12...
Things to try:
meteor reset
Delete the versions file
Locate and remove/rename tar.exe
Completely remove Meteor using a 3rd party uninstaller like Revo
This has been a problem for many months now so don’t hold your breath waiting for a fix…
But to going back to my original question: do you know whether backward compatibility for a legacy project developped with an old version of meteor is ensured by installing an old meteor version in the legacy project folder? Meaning that if I have 5 projects developped as at various times, I will end up having 5 different versions of Meteor installed on my machine?
After the reset, the release file says 1.4.1.1 in which my app started OK, but then many packages were updated to newer versions. I am more and more puzzled with the way meteor is handling versionning, since this meteor reset that I did seem to have, on the one hand, reverted back in time/version only for some core packages compared with the new version (1.4.1.2) that I had installed on my computer, since updated inside the project folder some newer versions of other packages.
In fact, it makes me wonder what is the precise definition of a meteor release?
Is it a set of core packages versions that have passed unit tests and are deemed compatible for having also passed integration tests.
Is all this versionning approach and process part explained in some part of the documentation?