Public release candidate of Meteor 1.2

core
106

RC 15 is now out, contains an important bugfix for running on android devices.

2 Likes
107

I’m also seeing slow rebuilds, not in the actual build time but in the time it takes for Meteor to start rebuilding. When I save a client-side file, it consistently takes 20-23s for Meteor to start rebuilding. Server-side files take 10-13s to trigger a rebuild. I do see a Node process spin up my CPU list immediately upon saving, but the cli takes the aforementioned amount of time to start updating (and thus the rebuild, and refreshing of browser, etc). This is running Meteor METEOR@1.2-rc.15.

108

For those always wanting the latest & greatest:

meteor update --release $(curl -sL http://bit.ly/latest-meteor-12-rc | sh)

This and a few other tips in this article. Would love your feedback - a few edits are already underway thanks to tips from all of you.

5 Likes
109

So, how do you recommend versioning these packages? Should you bump your package up a major version because it will no longer run on pre-1.2 versions of Meteor ?

For example, if you’re at 0.9.6 now (Meteor 1.1), and you go to Ecmascript, do you need to go to 1.x for Meteor 1.2 version ? Wouldn’t that necessitate maintaining the old branch to publish fixes like 0.9.7 for Meteor 1.1 users ? A fuller explanation of versioning packages across this transition would be welcome, thanks for all the great work !

1 Like
110

Yeah, probably it would make the most sense to bump the major version, although it doesn’t matter because your package will automatically get a dependency on a special fake package called isobuild:compiler-plugin so the version solver will be able to figure things out. I think you have it basically right.

Our goal is to navigate this transition by trying to get everyone to switch to Meteor 1.2 ASAP, so that people don’t have to support multiple versions of the package.

111

In Meteor 1.2.x I’d love to see improvements to versioning for package dependencies. As it stands now, its behavior conflicts with the documentation, and I find it pretty confusing.

112

Breaking changes in Meteor 1.2 document

Please help me proofread this document I’ve put together on the wiki about breaking changes in Meteor 1.2: https://github.com/meteor/meteor/wiki/Breaking-changes-in-Meteor-1.2

The idea is to write down the minimum set of changes you need to know about to keep your app running the same way as before. Let me know if something is not clear, or if I missed something!

113

Where does it conflict with documentation?

114
115

The documentation could be clearer, but I think it is technically correct (the best kind of correct!)

Basically, any version number matches any version greater or equal to that number up to the next major version.

To fill in your chart:

  • 1.0.0 matches 1.x.y
  • 1.2.0 matches 1.x.y where x >= 2
  • 1.2.7 matches 1.2.y where y >= 7, but also 1.x.y where x > 2
  • =1.2.7 matches only 1.2.7
  • no version number matches anything, and grabs the oldest version

In general, the version solver always picks the oldest set of packages that meet your constraints, so that you don’t accidentally get a newer version than what you are expecting. This is because newer versions of a package might contain unexpected new bugs or behavior.

116

But in my test, I included version 5.0.0 which installed 5.0.3, even though 5.4.0 was out. If 5.0.0 truly matches 5.x.y, then it would’ve installed 5.4.0, no? It installed 5.0.3 which is the last release before 5.1, so it seems that including 5.0.0 installs 5.0.y.

I’m curious why MDG didn’t just go with npm’s versioning system which is tried and tested (and pretty universally understood among JS devs), and also has syntax to prevent auto-updating to a breaking version.

117

You missed the end of my post I think. Just because a version is matched doesn’t mean it will be picked.

We have had a few internal discussions that this was the wrong way to do versioning, and that people probably expect to get the newest versions of stuff, not the oldest. I think you’re totally right in that the Meteor version constraint thing was based more on an academic understanding of what is more compatible than on what people actually would expect or want.

For much much much more detail about the issue, see @dgreensp’s post on Hackpad: https://meteor.hackpad.com/Packaging-UX-Gravity-Hurts-FoTnLTVUklt

(For context, David Greenspan is the person who actually wrote Meteor’s version solver)

If you want to discuss more about this topic it’s probably best to take it to a different thread.

1 Like
118

Links to the API docs for new stuff would be useful: these jump out at me: api.addAssets (package.js), Accounts.findUserByUsername, Accounts.findUserByEmail, react (package), react-runtime (package), getMeteorData

Not sure how practical this will be until the 1.2 docs are published, but you did ask :wink:

1 Like
119

It’s not letting me use jsx with the new ecmascript package. Is this by design? I do not like that. Babel supports it, so at the very least I should be able to enable it, not need to go out and get another dependency.

120

@rozzzly you need to add the jsx package. The idea is that you can use different packages for compiling JSX and JavaScript if you want.

If you don’t want, feel free to use the old Babel package.

121

After upgrading to rc16 it throws an error:
W20150917-15:45:54.186(-4)? (STDERR) ReferenceError: Meteor is not defined
W20150917-15:45:54.186(-4)? (STDERR) at lib/router.js:11:1
W20150917-15:45:54.186(-4)? (STDERR) at lib/router.js:150:1
The code on these lines is just: if (Meteor.isClient) {}
PS: I’m using Iron-Router

122

Is this a new error? As in did the previous RCs not have it?

123

Same slow pickup in changed files and rebuild times in rc16 as well.

124

I didn’t try the previous version. The last one I tried was RC13 and it didn’t compile my bower packages. Now bower packages are fine but have an error with ReferenceError: Meteor is not defined which is located in lib/router.js file.
Here’s a snippet:


    if (Meteor.isClient) {
      // SubsManager package for subscriptions caching
      var subsManager = new SubsManager({
        // maximum number of cache subscriptions
        cacheLimit: 20,
        // any subscription will be expire after 5 minute, if it's not subscribed again
        expireIn: 2
      });
    
      Router.map(function() {
        this.route('welcome', {
          path: '/'
        });
      });
    }
125

There is probably some important piece of information missing from this reproduction, otherwise nobody’s apps would run at all. Is there something else in the error output, interesting packages you might be using, etc?