After upgrading to 184.108.40.206 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 email@example.com_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 firstname.lastname@example.org_1… \
So now my app does not start with 220.127.116.11 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 am on Windows 7.
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
Things to try:
- Delete the versions file
- Locate and remove/rename
- 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…
Hi Manuel and thank you for your quick reply.
I managed out of this extraction loop by uninstalling git as discovered by emoen on meteor gitbub issue 7766 https://github.com/meteor/meteor/issues/7766
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 18.104.22.168 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 (22.214.171.124) 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?
Ah, and one more thing.
Are the beta releases only available for OSX and Linux but not Windows?