Packages can't specify compatibility with multiple major versions

[aldeed]

Copied my comment from #2521:

I tried @alanning's suggestion of removing api.versionsForm and specific versions for core packages, and although it will run fine locally, meteor publish does not let you publish it. This seems like a pretty big oversight. There is no way to not specify a version and there is no way to specify multiple major versions, so... no way to have your package work on both Meteor 0.9.0 and Meteor 0.9.1.

I would suggest simple ability to specify version ranges for each version piece:

• @1+.0.0
• @1-2.0.0
• @1.0+.0+

And comma support for trickier cases:

• @1.6+.0+,2.0+.0+

It's fine to continue to use semver rules as the default for app dependencies, but package authors should have complete control of each version piece for package dependencies.

[aldeed]

Here's an example:

Package.on_use(function(api) {
  api.versionsFrom('METEOR@0.9.1');
  api.use('blaze');
}

A package with this will not run on 0.9.0. But if you change it to:

Package.on_use(function(api) {
  api.versionsFrom('METEOR@0.9.0');
  api.use('blaze');
}

Then it won't run on 0.9.1.

And if you do only:

Package.on_use(function(api) {
  api.use('blaze');
}

Then it will run fine on both but meteor publish command will say:

You must specify a version constraint for the following packages: check

[alanning]

This is getting ridiculous. api.versionsFrom as it is now is an anti-pattern and we also can't specify a range for specific packages.

Here is an example repo for people to try these things out with:
https://github.com/alanning/meteor-test-versionsFrom

[alanning]

Relevant Links:

• Error after upgraded to Meteor 0.9.1 - Error after upgraded to Meteor 0.9.1 #2521
• 0.9.1 support for roles - incompatible with METEOR@0.9.1 Meteor-Community-Packages/meteor-roles#53
• Meteor-Core 0.9.1 discussion - https://groups.google.com/d/msg/meteor-core/s-xGYQ3gBkc/KBw3Lpvx-UQJ

[Tarang]

I also had this problem with my packages. Thing is the package is compatible, just Meteor says its not because of the api.versionsFrom, specifically with 0.9.1 and 0.9.0 being on their own. (and again with the rcs for 0.9.2, and previous 0.9.1-rc*

It would be very frustrating to keep packages up to date with every small version bump in Meteor this way.

[alanning]

To clarify my thoughts on this, I do not believe it is reasonable to expect package authors to maintain separate code bases, yet that seems to be the current state of the world with Unipackage.

For example, imagine there is some incompatibility with a new version of Meteor (this issue, for example). Even if there is a way to handle this in the package code itself (as shown in the meteor-0.9.1 branch of roles), there is no way to publish the package and let meteor know it works for multiple versions. So we can't keep a single package.js and must maintain separate branches. Now when we want to update the functionality in the roles package, changes must be made in master as well as all version branches.

So as @glasser points out in the name change, the goal is to allow packages to target multiple meteor versions.

But... I don't think that's even necessary. I can't imagine package authors wanting to support version 0.9-0.9.3 on this branch, 0.9.4-0.10 on that branch, and so on.

What would be useful is to treat api.versionsFrom('METEOR@0.9.0'); as a MINIMUM compatible version and giving us some way to view the specific version of meteor in the package itself.

We tell meteor this package is compatible with Meteor 0.9.0 and above and handle any specific workarounds in the package code without having to maintain different codebases.

[aldeed]

I agree somewhat with what @alanning said, but multiple-major-version support is also needed for community packages, where api.versionsFrom does not come into play at all.

For example, my autoform pkg has a weak dependency on my collection2 pkg. If there are three major versions of collection2 due to non-backwards-compatible releases, but autoform works fine with any of them, then in autoform I want to depend on aldeed:collection2@1-3.0.0. I don't want >=1 for the major version because I'll want to test each major release of collection2 before I indicate that autoform supports it. I want to say specifically that 1, 2, or 3 (and minor/patch releases within those) are fine to use.

[aldeed]

Another aspect of this is package name changes. There should be a clear way to indicate that either ui@versions or blaze@versions must exist, but they are not weak dependencies because they are collectively a strong dependency. But it shouldn't cause a problem if MDG, for example, eventually removes the ui pkg entirely.

Maybe that's another issue entirely, but seems related to the idea of being compatible with multiple major versions.

[raix]

In some sense its ok to specify the version expecting it to work in greater versions accordingly to semver.
But imho it could make sense to do:

Package.onUse(function(api) {
  // Version 0.9.1 and above
}, 'METEOR@0.9.1');

Package.onUse(function(api) {
  // Version 0.9.0 and above
}, 'METEOR@0.9.0');

// EDIT:
Package.onUse(function(api) {
  // Version 0.9.0 and above
  // and
  // Version 0.9.1 and above
}, ['METEOR@0.9.0', 'METEOR@0.9.1']);

Not sure how this would work on pre-0.9.0 projects

[alanning]

@raix, in that case the onUse block should target a specific version I think, rather than X and above, right? Add in SEMVER support for the "and above" part:

Package.onUse(function (api) {
  // Version 0.9 up to but not including 0.10
}, 'METEOR@0.9');

(This is reminiscent of the browser version vs. feature detection problem.)

[raix]

@alanning I so in that case the package should be updated to:

Package.onUse(function(api) {
  // Version 0.9.1 < 0.10.0
}, 'METEOR@0.9.1');

Package.onUse(function(api) {
  // Version 0.9.0 < 0.9.1
}, 'METEOR@0.9.0');

// Common for 0.9.0 and 0.9.1
Package.onUse(function(api) {
  // Version 0.9.0 - 0.9.1 < 0.10.0
}, ['METEOR@0.9.0', 'METEOR@0.9.1']);

Package.onUse(function(api) {
  // Version 0.10.0 and above
  // non of the stuff from the other onUse will load here eg. 0.9.0, 0.9.1 files will not load
  // since the on use package meteor version will be set to 0.10.0 if meteor is 0.10.0 or
  // above
  throw new Error('Sorry dude this version of Meteor is not supported yet');
}, 'METEOR@0.10.0');

[gadicc]

@aldeed, what was the error when you tried to publish without versionsFrom ? I managed to do it fine now without a problem. In light of my example at [meteor-talk] 0.9.1 release candidate! it definitely makes more sense to lock to individual package versions than Meteor versions.

Update: Oh sorry, you did say... and you don't use the check package anywhere? and if you give blaze a version like api.use('blaze@2.0.0', 'client')?

[raix]

@gadicc so going from 0.9.0 to 0.9.1 may not break api if following semver...http://semver.org (To my understanding the new package system should be semver compliant - for consistency so should the meteor versions imho)

When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.

[raix]

going from 0.9.0 to 0.9.0 is a patch - but mdg is using 0.9.1.1 as patch versions? - I guess mdg is doing this to reach the symbolic 1.0.0 - but perhaps we should really change our different view on versions eg. get away from the notion of a version 1 and version 2 etc. having a more fluid transition making the users want to run the newest version of Meteor.

[gadicc]

@raix that's a good point... should the Meteor of version itself (Meteor being a collection of smaller packages) be semver compliant? It means that Meteor must change major versions any time any package changes major versions. I'll let MDG answer this one :)

[raix]

@gadicc We better :)
Note: most packages are a collection of smaller packages too - so if implying on of those packages changes / deprecates an api then the major version should be bumped. A package collection as the "Meteor-platform" should follow this too - but if one creates backwards compatibility then a minor version bump on meteor should be ok too. Enough from me - I'll stop cluttering this issue...

[aldeed]

@gadicc, leaving out api.versionsFrom works fine if you pin the individual packages. The error happens when you try to leave out api.versionsFrom and leave out individual package versions for core packages, which is the only way I can think of to support both 0.9.0 and 0.9.1 when you depend on, for example, blaze.

[aldeed]

@raix, regarding multiple Package.onUse, I wouldn't enjoy having to define the files multiple times or move the other onUse code to a helper function. I would prefer to change only the dependencies calls based on Meteor version.

[gadicc]

@aldeed, ok, gotcha. I don't think it makes sense to specify no version, because then there's no way then to work out the constraints under which your package would work. But as per the rest of the thread I do see the need to be able to tell the package server that we support multiple versions of the same package, and then have a way to do conditional code. I'll also keep quiet now until I have something more constructive to say :)

[cmather]

I didn't realize this thread existed until a second ago so I'm cross posting my comment from iron:router.

iron-meteor/iron-router@43f2007#commitcomment-7701451

There are currently two release candidate tracks of Meteor - 0.9.1 and 0.9.2. In order for there to be a version of iron:router that works with each release candidate (across two MDG release tracks) I need to publish versions of iron:router (and all 7 dependent packages) for every single release candidate. And then users need to know which version of iron:router works with each release candidate and/or major version. Since this isn't a feasible use of time I'll need to pick a release track and one will just be unsupported. For example, the 'next' branch of iron:router is tracking 0.9.2. But even on that branch I have to publish a new release for each corresponding MDG release candidate.

Some of the solutions on this thread seem promising. I wonder if there's also a way to recommend a version of a package that would work given a Meteor release. Perhaps a less scary option than saying "meteor update". So if you're on --release 0.9.2-rc1 and you have iron:router installed you get a nice message that says, 'Hello my friend would you like to upgrade to iron:router@x.y.z that works with this version of Meteor?

[glasser]

@cmather For what it's worth, there are a couple things bound up in your comment. We have a plan in mind to improve the RC-specific case that @ekatek is probably implementing this week. Separately, the fact that you need to maintain separate branches (or use wacky conditionals or something) to support multiple major versions of a package is something that needs to be addressed, but it's somewhat different.

@alanning When you say

I can't imagine package authors wanting to support version 0.9-0.9.3 on this branch, 0.9.4-0.10 on that branch, and so on.

note that when I changed the name to "multiple major versions", I meant multiple major versions of packages, not releases. The thing that made 0.9.1 tricky is that there was in fact a major version bump of blaze inside it.

As folks have noticed, packages use semver whereas releases do not. That's because releases describe the full platform. We expect different pieces of the platform to take major version bumps at different times; if we had to do a major version bump of the whole Meteor platform every time that a niche-use-case core package took a major version bump, it really wouldn't describe the impact of a new release on an average app developer.

[mitar]

As folks have noticed, packages use semver whereas releases do not. That's because releases describe the full platform. We expect different pieces of the platform to take major version bumps at different times; if we had to do a major version bump of the whole Meteor platform every time that a niche-use-case core package took a major version bump, it really wouldn't describe the impact of a new release on an average app developer.

Why? Increasing patch versions should be for such backwards compatible changes. Increasing minor version is for new stuff, but still backwards compatible. The problem is that you are trying to release 0.9.2 which will have a new feature (Cordoba), which is problematic. How do you expect an average app developer to understand many changes happening with 0.9.2, that it is not just a patch increase, but completely new feature?

[ekatek]

Thanks for this thread, all. This (and the mailing list traffic, and other interactions) have convinced us that probably we should put out something supporting this soon, if not in 0.9.3, then probably in 0.9.4. Not sure what the syntax will look like yet (thanks, again, for all the suggestions in this thread!), but thank you all, again, for your feedback. I'll keep y'all updated, as the work on this progresses.

[ekatek]

We have put out 0.9.3-rc6, that replaces '' with '_'. (For the one non-test package that published a '' version, we went ahead and changed it to ''). We have also changed the packages server to use '' instead of '~', so if you try to publish with the wrong character, it will not work.

[aldeed]

Solved by 0.9.3, as far as I'm concerned. Closing.

[dandv]

What's the difference between

api.versionsFrom('METEOR@0.9.4');

and

api.versionsFrom('0.9.4');

?

[ekatek]

Convenience. They mean the same thing.

On Fri, Oct 24, 2014 at 4:43 PM, Dan Dascalescu notifications@github.com
wrote:

What's the difference between

api.versionsFrom('METEOR@0.9.4');

and

api.versionsFrom('0.9.4');

?

—
Reply to this email directly or view it on GitHub
#2531 (comment).