package system defaults to ancient versions if no semver is specified?

[dcsan]

if add a package with no semver specified it will default to the oldest version:

# .meteor/packages
aldeed:autoform

$ meteor update
  downgraded aldeed:autoform from version 4.0.0 to version 0.17.1
  downgraded aldeed:collection2 from version 2.2.0 to version 0.4.6

at the very least this seems wrong, it should default to the newest version?

separately, if I specify a recent version, however there is no way to say "at least 4.0" with meteor's flavor of semver. both of these:

   aldeed:autoform@4.0.0
   aldeed:autoform@=4.0.0

will pull in 4.0.0 where currently that package is at 4.2.0 .
afaik there is no support for something like

aldeed:autoform@>4.0.0

[glasser]

Can you provide a full cloneable reproduction? Ideally with 1.0.2-rc.1.

[dcsan]

I can't repro this with 1.0.2

which btw seems blazingly fast at reloading everything!! if this is the long awaited speedup code drop, there's no way i'm going back to 1.0 :) woohoo!

[RobertLowe]

@glasser I ran into the same issue when running a routine meteor update from 1.0.2 to 1.0.2.1 now my deps are trying to depend on older versions, even after trying to downgrade back to meteor update --release 1.0.2.

The issue for me was with aldeed:autoform & aldeed:collection being downgraded to 0.1.0.

I fixed the issue by removing the offending packages from .meteor/packages which had deps on it, running meteor add aldeed:autoform@4.2.0 then meteor add aldeed:collection2@2.3.0, I then updated the local packages deps to include specific versions, removed the two packages from .meteor/packages. Finally I restarted meteor and it was satisfied.

Something about meteor update, meteor add and unspecified versions works a little wonky.

I can't push this to a public repo either.

Cheers.

[glasser]

@dgreensp Is this something you can look into, since you're working on stuff with the constraint solver anyway? The constraint solver is definitely supposed to try hard to avoid downgrading anything if possible.

[dgreensp]

I can look into it.

Thoughts off the top of my head: The constraint 4.0.0 does mean "at least 4.0.0 (but less than 5.0)". meteor update is supposed to prefer newer versions. However, the currently released solver doesn't globally optimize, or even try very hard to locally optimize once all constraints are satisfied. I'm working on a rewrite of the constraint solving algorithm that should help.

As always, cloneable reproductions are greatly appreciated.

[dgreensp]

Reopening.

See also https://groups.google.com/forum/#!topic/meteor-talk/dN415Rbcvg0

[dgreensp]

@RobertLowe, to clarify, your problem was with packages being downgraded that weren't listed in .meteor/packages, but were dependencies of packages listed in .meteor/packages, correct?

[RobertLowe]

@dgreensp Yes, I believe that's the case, I'm mobile right now so if memory serves that is correct.

It happens when dependacies are left unspecified.

Cheers

[dgreensp]

Fixed on devel.

What meteor update foo means is: Update the version of foo in .meteor/versions, and also edit the versions of its dependencies as necessary to satisfy all constraints. The constraints on direct dependencies in .meteor/packages are maintained at all times. Before this fix, meteor update foo only did-what-you-meant if foo was a direct dependency. If foo was an indirect dependency (depended on by a package), it would actually downgrade foo instead of upgrading it. This is now fixed.

[RobertLowe]

Thanks @dgreensp you're awesome!

[arunoda]

This may be somewhat related to this issue.

• I've pushed my app into git from a mac
• Then I trying to build it from a CI server (linux)
• Then I see something like below:

=> Started proxy.

Changes to your project's package version selections:

anti:gagarin                 downgraded from 0.3.3 to 0.3.0
meteorhacks:flow-components  downgraded from 0.0.20 to 0.0.13
meteorhacks:flow-router      downgraded from 0.0.12 to 0.0.2

None of these is a binary package. I think this is something relevant to this issue.
Is this fix comes with 1.0.3-rc.0 ?

[dgreensp]

Did you commit .meteor/versions? Just running the app shouldn't change the versions for no reason.

[arunoda]

Ah yes. it's there.
That's why it's mentioning downgraded from 0.3.3 to 0.3.0
(0.3.3 is the version in the .versions file)

[RobertLowe]

@dgreensp OT: Is there a way to dump a dependancy's tree of dependancies? This would be fairly useful... As of right now it's a bit difficult to see what a dependancy is built on top of other then digging through atmosphere.

Cheers

[dgreensp]

@arunoda If you revert .meteor/versions and run again, does it downgrade again, reproducibly? That sounds like a bug that I'd like to reproduce. However, I suspect it is because if anything triggers a full run of the constraint solver, indirect dependencies may get downgraded. That suggests a second question. After you get the "downgraded" message, if you change only those versions back to what they were, does it downgrade again?

My fix only address what happens when you run meteor update, but it allows you to run meteor update anti:gagarin meteorhacks:flow-components meteorhacks:flow-router and have it work even if those packages aren't direct (i.e. top-level) dependencies. The fix is included in 1.0.3.

@RobertLowe You're in luck. There's no tree, but as of 1.0.3-rc.0, meteor show foo-package@1.0.0 will list the dependencies of foo-package@1.0.0. Thanks go to ekate for this feature.

[arunoda]

@dgreensp It's hard to reproduce. Only happens on some linux boxes only. Yes, if I updated again with meteor update it will work correctly.

I try to find if it can be reproduced. Then I'll share the linux VM with you.

[queso]

I am getting this with codeship test running. When I run the app in the codeship environment, it downgrades the app from 0.3.6 to 0.3.4 (xolvio:cucumber) for some reason.

Will see if I can make a quick repro of it.

[krstffr]

I'm getting this error when deploying to Heroku servers using the https://github.com/AdmitHub/meteor-buildpack-horse buildpack. Random packages get downgraded unless I specify an exact version for them (running meteor add author:package@1.2.3 for example).

[queso]

Yes, mine turned out to be the same issue, with no semvar it seemed to just randomly downgrade. Once I pegged xolvio:cucumber@0.3.6, it worked fine on install.

@glasser should we open a new issue since this one is closed?

[dgreensp]

Is there any way we can reproduce this? I'd love to get to the bottom of it!

The part that's hard to figure out is that meteor should use the versions in .meteor/versions, which should be checked into your repo. If it needs to choose different versions for some reason -- which may be possible to trigger based on architecture? I'm not sure -- it should write the new versions to .meteor/versions. So you should at least be able to see the "paper trail" in .meteor/versions, and reproduce the downgrade repeatedly by reverting it.

Are you able to get the message repeatably? Thanks.

[queso]

I will see if I can get a simple repo up and repro on codeship... It has a debug console so you can ssh in and play around with the box directly... I have seen it happen 2 out of 2 times on codeship so far without cucumber being pegged to a version.

[queso]

@dgreensp I assume MiniSat should solve this?

[dgreensp]

My understanding is that this issue and #3653 are fixed on devel, and in the METEOR@new-version-solver-2 release (and the upcoming 1.1 RC).