Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 1.6.1 #9274

Merged
merged 486 commits into from Jan 20, 2018

Conversation

@benjamn
Copy link
Member

commented Oct 30, 2017

Now that Meteor 1.6 has been finalized and officially recommended, it's time to get started on the next 1.6.x version, 1.6.1.

To be clear, there is no immediate urgency to this release, since Meteor 1.6 seems to be working well for most developers. 馃

See the Release 1.6.1 milestone for a partial list of issues we hope to tackle in this release.

@benjamn benjamn added the in progress label Oct 30, 2017

@benjamn benjamn added this to the Release 1.6.1 milestone Oct 30, 2017

@benjamn

This comment has been minimized.

Copy link
Member Author

commented Oct 31, 2017

I've also started putting feature requests that we might consider into a milestone here: https://github.com/meteor/meteor-feature-requests/milestone/1

@zimme

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2017

Bump node to 8.9.0? Seems like that's the latest LTS for now.
My bad, just saw the commit.

@benjamn

This comment has been minimized.

Copy link
Member Author

commented Nov 1, 2017

Just in case anyone disagrees, I don't see anything in Node 8.9.0 (compared to 8.8.1) that makes me think we should release Meteor 1.6.1 immediately. If anyone can demonstrate anything that works in 1.6.1-beta.1 that doesn't work in Meteor 1.6, I'd be happy to reconsider.

@brucejo75

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2017

@benjamn, your comment: #9274 (comment); makes me wonder if you will have a policy on keeping up with Node versions? Meteor seems very flexible with regard to taking new node versions today (thank you!), so it may be worth a discussion.

I think you are right to not chase every version of node, but should you do a catch up build Monthly? Quarterly? Or will it be based on specific node versions?

I also guess it may be fair to ask what your policy is on releasing versions of Meteor that are riding on the current release along with the LTS release of node? It may be time to support the latest node in parallel with LTS node?

I think committing to a certain cadence of node driven releases could be helpful to the community. Thoughts?

@hwillson

This comment has been minimized.

Copy link
Member

commented Nov 1, 2017

@brucejo75 Just a quick FYI - there is a somewhat related discussion over in meteor/meteor-feature-requests#110 regarding a LTS plan for Meteor as a whole.

@axelvaindal

This comment has been minimized.

Copy link

commented Nov 2, 2017

Nice follow up for the already amazing 1.6 version.

I would really appreciate to see further details about a LTS plan for Meteor as a whole, as it would be nice to see planned feature evolution and bug solving for upcoming Meteor version.
I know there is the ROADMAP.md file and milestones, but perhaps something more user friendly could be implemented, such as :

  • Indicate the state of LTS support for Meteor version in the documentation website, with due date and breaking changes for each version.
  • Use Github Project for issue separation and version triage based on milestone (as they do in the npm repository for example). I believe to know there used to be an official Trello long time ago with the roadmap and always wondered why it was abandoned back then. The milestone viewing as the disadvantages of not showing actual progress of every issues covered.
  • Provide clearer information about incoming feature for the Meteor core in the upcoming version (by opening locked issue when the feature is developed internally perhaps). I think of this because I only knew Meteor was implementing dynamic imports in v1.5 because I read the PR and it was mentioned, for example.

I often use this repository as a reference (more specifically the PR's) for what's coming next, and I suppose lots of developer do the same, so maybe it could be clearer what is the main preoccupation of the MDG in the upcoming version and how we can get involved in order to contribute or work on giving some assistance.
For instance, 26 opened issues and feature requests are pull-request-encouraged and I would have felt it so much easier to contribute if I'd known where to start to begin with. Most of them are not in the "roadmap scope" so how is the community feeling about it being implemented ? What are the real needs and urgences ?

It's more about priorisation and accessibility than how to do things considering the CONTRIBUTING.md file is quite explicit (and I would be so happy to see it integrated in the guide as well).

I stop this here, considering it's not quite the subject, I would be happy to transfer this comment if needed (the linked conversation has no one talking since June, thus my message is here).

@yoann54

This comment has been minimized.

Copy link

commented Nov 3, 2017

A way to implement PWA would be great. Is that plan or in discussion ?

@benjamn benjamn force-pushed the release-1.6.1 branch from 0f0e403 to f91ff78 Nov 6, 2017

@jamesmillerburgess

This comment has been minimized.

Copy link
Contributor

commented Nov 7, 2017

I'm getting an error when building my app with 1.6.1-beta.2:

$ meteor
[[[[[ ~/projects/customer-management ]]]]]

=> Started proxy.
=> Started MongoDB.
/Users/goldfibre/.meteor/packages/meteor-tool/.1.6.1-beta.2.14xe6k7.1nhsk++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/fibers/future.js:313
                                                throw(ex);
                                                ^

TypeError: Cannot read property 'toLowerCase' of undefined
    at ImportScanner._getFile (/tools/isobuild/import-scanner.js:184:23)
    at each (/tools/isobuild/import-scanner.js:735:26)
    at _.each._.forEach (/Users/goldfibre/.meteor/packages/meteor-tool/.1.6.1-beta.2.14xe6k7.1nhsk++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:87:22)
    at ImportScanner._scanFile (/tools/isobuild/import-scanner.js:719:5)
    at each (/tools/isobuild/import-scanner.js:809:12)
    at _.each._.forEach (/Users/goldfibre/.meteor/packages/meteor-tool/.1.6.1-beta.2.14xe6k7.1nhsk++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:87:22)
    at ImportScanner._scanFile (/tools/isobuild/import-scanner.js:719:5)
    at each (/tools/isobuild/import-scanner.js:809:12)
    at _.each._.forEach (/Users/goldfibre/.meteor/packages/meteor-tool/.1.6.1-beta.2.14xe6k7.1nhsk++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:87:22)
    at ImportScanner._scanFile (/tools/isobuild/import-scanner.js:719:5)
    at each (/tools/isobuild/import-scanner.js:809:12)
    at _.each._.forEach (/Users/goldfibre/.meteor/packages/meteor-tool/.1.6.1-beta.2.14xe6k7.1nhsk++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:87:22)
    at ImportScanner._scanFile (/tools/isobuild/import-scanner.js:719:5)
    at each (/tools/isobuild/import-scanner.js:809:12)
    at _.each._.forEach (/Users/goldfibre/.meteor/packages/meteor-tool/.1.6.1-beta.2.14xe6k7.1nhsk++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:87:22)
    at ImportScanner._scanFile (/tools/isobuild/import-scanner.js:719:5)
    at each (/tools/isobuild/import-scanner.js:756:14)
    at _.each._.forEach (/Users/goldfibre/.meteor/packages/meteor-tool/.1.6.1-beta.2.14xe6k7.1nhsk++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:87:22)
    at ImportScanner._scanFile (/tools/isobuild/import-scanner.js:719:5)
    at outputFiles.forEach.file (/tools/isobuild/import-scanner.js:414:14)
    at Array.forEach (<anonymous>)
    at ImportScanner.scanImports (/tools/isobuild/import-scanner.js:412:22)
    at sourceBatches.forEach.batch (/tools/isobuild/compiler-plugin.js:1044:17)
    at Array.forEach (<anonymous>)
    at Function.computeJsOutputFilesMap (/tools/isobuild/compiler-plugin.js:1012:19)
    at ClientTarget._emitResources (/tools/isobuild/bundler.js:1057:8)
    at buildmessage.enterJob (/tools/isobuild/bundler.js:828:12)
    at /tools/utils/buildmessage.js:359:18
    at exports.EnvironmentVariable.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:352:34
    at exports.EnvironmentVariable.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:350:23
    at exports.EnvironmentVariable.withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.enterJob (/tools/utils/buildmessage.js:324:26)
    at ClientTarget.make (/tools/isobuild/bundler.js:819:18)
    at /tools/isobuild/bundler.js:2927:14
    at /tools/isobuild/bundler.js:3016:20
    at Array.forEach (<anonymous>)
    at Function._.each._.forEach (/Users/goldfibre/.meteor/packages/meteor-tool/.1.6.1-beta.2.14xe6k7.1nhsk++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
    at /tools/isobuild/bundler.js:3015:7
    at /tools/utils/buildmessage.js:271:13
    at exports.EnvironmentVariable.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:264:29
    at exports.EnvironmentVariable.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:262:18
    at exports.EnvironmentVariable.withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:253:23
    at exports.EnvironmentVariable.withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.capture (/tools/utils/buildmessage.js:252:19)
    at bundle (/tools/isobuild/bundler.js:2908:31)
    at files.withCache (/tools/isobuild/bundler.js:2855:32)
    at Object.withCache (/tools/fs/files.js:1658:12)
    at Object.exports.bundle (/tools/isobuild/bundler.js:2855:16)
    at Profile.run (/tools/runners/run-app.js:579:36)
    at Function.run (/tools/tool-env/profile.js:490:12)
    at bundleApp (/tools/runners/run-app.js:578:34)
    at AppRunner._runOnce (/tools/runners/run-app.js:622:35)
    at AppRunner._fiber (/tools/runners/run-app.js:880:28)
    at /tools/runners/run-app.js:408:12

There is no error when building the same app with 1.6.1-beta.1.

benjamn added a commit that referenced this pull request Nov 7, 2017

@jamesmillerburgess

This comment has been minimized.

Copy link
Contributor

commented Nov 8, 2017

The errors stopped appearing in 1.6.1-beta.3 馃憤

@yorrd

This comment has been minimized.

Copy link

commented Nov 17, 2017

Just FYI, not sure if you're aware of it. With the last release (beta.8), there is (still since 1.6.1 generally) this issue:

When using groundDB, you'll get this error. I have no idea what caused this but I have noticed you were working on ddp packages.

Exception in setInterval callback: TypeError: conn._subscriptions.every is not a function
    at http://localhost:3000/packages/ddp-client.js?hash=a1fa33e4aeae4bee09da68cd101a60c6edddbd81:2369:32
    at Array.every (<anonymous>)
    at Object.DDP._allSubscriptionsReady (http://localhost:3000/packages/ddp-client.js?hash=a1fa33e4aeae4bee09da68cd101a60c6edddbd81:2368:25)
    at http://localhost:3000/packages/ground_util.js?hash=c64bc1a5ca0079a083c8afc594e4460a2d0c0c44:130:11
    at Meteor.EnvironmentVariable.EVp.withValue (http://localhost:3000/packages/meteor.js?hash=b0f12795c8cc1423b5850502871996903f947ed5:1140:15)
    at http://localhost:3000/packages/meteor.js?hash=b0f12795c8cc1423b5850502871996903f947ed5:521:25
    at http://localhost:3000/packages/meteor.js?hash=b0f12795c8cc1423b5850502871996903f947ed5:1167:22

abernix added a commit that referenced this pull request Nov 20, 2017

Correct accidental use of `Array.prototype.every` on an Object.
Fixes the error reported in the 1.6.1 pull request. (Thanks, @yorrd!)

It's worth nothing that the `DDP._allSubscriptionsReady` function which
was broken is used by the deprecated `spiderable` package.  Since
`spiderable` is deprecated, it's advisable to look into ways to stop
depending on it.

Refs: #9274 (comment).
@abernix

This comment has been minimized.

Copy link
Member

commented Nov 20, 2017

Thanks, @yorrd. That should be fixed with 2a62bca, which will be merged into this PR soon has been merged into this PR.

@bmanturner

This comment has been minimized.

Copy link

commented Nov 20, 2017

Upgrading from 1.6 to 1.6.1-beta.8 gave me the following error:

TypeError: Class constructor Collection cannot be invoked without 'new'
    at new ns.Collection (packages/matb33_collection-hooks.js:275:27)
    at new SuperCollection (packages/pindigo:collections/main_global.js:3:1)
    at main_global.js (packages/pindigo:collections/main_global.js:26:18)
    at fileEvaluate (packages/modules-runtime.js:343:9)
    at require (packages/modules-runtime.js:238:16)
    at hashtags.js (packages/pindigo:collections/indexes/hashtags.js:1:27)
    at fileEvaluate (packages/modules-runtime.js:343:9)
    at require (packages/modules-runtime.js:238:16)
    at index.js (packages/pindigo:collections/indexes/index.js:1:14)
    at fileEvaluate (packages/modules-runtime.js:343:9)

Which happens here:

  **class SuperCollection extends Meteor.Collection {**
    async aggregate(pipeline = []) {
      return this.rawCollection().aggregate(pipeline, { allowDiskUse: true }).toArray();
    }
  // ...

Let me know if I need to open a new issue, please.

@klaussner

This comment has been minimized.

Copy link
Collaborator

commented Nov 20, 2017

@bmanturner That looks like the issue reported in #9383.

benjamn and others added some commits Nov 22, 2017

Merge pull request #9398 from sebakerckhof/fix/stop-npm-wasting-all-m鈥
鈥-time

Don't update npm dependencies when it's not needed
Update the default CSS parsing/combining/minifying tools (#9263)
* Update the default CSS parsing/combining/minifying tools

The `minifier-css` package is currently using outdated
(and abandoned) npm packages (`css-parse` and `css-stringify`),
as part of its parsing/minification process. This commit
replaces those packages with the robust, modern and maintained
`postcss` package.

* Adjust CSS source file fallback value

* Self test adjustments and cleanup

* Disable sourcesContent generation by postcss

The `standard-minifier-css` package is already associating
source content with the source map, so we don't need to
do this twice.

* Add History.md entry covering backwards compatibility details

* Bump major version due to backwards compatibility breaking changes

* Bump minor versions

* Code review changes (boolean formatting, concat to spread)
Fix meteor test file matching patterns (#9339)
* Adjust test filename RegExps to match Meteor guide. Fixes #9332.
* Adjusted help text for --drive-package on meteor test.
* Add integration tests for `meteor test` eager file loading.
* Fix typo in selftest.forbid comment.
* Improve test file eager load integration test coverage and clarity.
Merge pull request #9396 from meteor/abernix/mongo-3.4
Use Mongo 3.4 for 64-bit platforms.
@KoenLav

This comment has been minimized.

Copy link

commented Jan 17, 2018

@benjamn your reply is much appreciated, and I recognize the fact that distributing resources over various projects is challenging ;)

For us, much of the value of Meteor comes from being able to utilize native capabilities (mainly raw TCP socket communication on a local network) from the webview. The importance of these native capabilities is quickly fading, as HTML5 is covering most of them. Hence I understand that there is less focus on 'the past' (Cordova/Electron) and more on the future (web/HTML5). However, for our application (and I can imagine quite some others), native capabilities are still required.

I have not yet tried the Meteor 1.6.1 RC with Cordova on our application, but I'll try to run some tests over the weekend.

It's really good to hear you are actively working on the Cordova support; I just wanted to make sure the issues in the cordova-plugin package weren't overlooked (although they are smaller, they are quite challenging for business applications).

Unrelated note: I think the stability improvements Meteor has delivered from 1.3 -> 1.4 -> 1.5 -> 1.6 are huge. We started working with Meteor at 1.0 and it has been quite a bumpy ride, but currently I believe there isn't a better framework available for applications that require live data/cross platform support/native capabilities.

benjamn added some commits Jan 17, 2018

Improve node_modules portability scan.
In an attempt to fix #9552, recursively scan child directories of
directories that start with '@' characters, rather than treating the
parent directory as a potential npm package.

Also, ignore directories that start with a '.' character, such as the
common node_modules/.bin directory.
Write .meteor-portable-2.json files synchronously.
Previously these files were written asynchronously in an attempt to
improve performance, since the success of the write is not critical.
While I stand by my claim that it's acceptable for these writes to fail, I
noticed recently that the async write was failing very often (resulting in
an empty .meteor-portable-2.json file). Switching to sync semantics
eliminated that problem with no noticeable loss of performance. In fact,
overall performance is likely better because of the future work saved by a
successful write.

@benjamn benjamn force-pushed the release-1.6.1 branch from 5c74064 to a3cb642 Jan 19, 2018

benjamn added some commits Jan 19, 2018

Avoid hiding errors due to missing dependencies of custom Babel plugins.
As illustrated by #9554, if a custom .babelrc plugin such as
@babel/plugin-proposal-optional-chaining imports a missing dependency such
as @babel/core, that failure causes inputFile.require to throw an
exception that looks a lot like @babel/plugin-proposal-optional-chaining
itself is missing, which can be confusing.

This change does not fix the underlying problem (the @babel/core package
still needs to be installed), but it does expose the exception so that the
developer can do something about it, rather than merely leaving the ?.
syntax uncompiled.

Here's the offending line of code:
https://github.com/babel/babel/blob/47ce7e71c9f97d151be493d05755562cb299fcca/packages/babel-plugin-proposal-optional-chaining/src/index.js#L2

Unfortunately, depending directly on @babel/core seems to be the policy
for Babel plugins, per this PR: babel/babel#6778

@benjamn benjamn force-pushed the release-1.6.1 branch from a3cb642 to 6ae1473 Jan 19, 2018

benjamn added some commits Jan 19, 2018

Go back to writing .meteor-portable-2.json files asynchronously.
This reverts commit 4e4e204.

This commit caused a strange regression in reliability of the Windows
dynamic-import self-test, which may be an indication of a deeper problem,
so it seems safest to revert this change for now.

In case empty .meteor-portable-2.json files are written, I've added an
additional check that the cached JSON value is a boolean.
@benjamn

This comment has been minimized.

Copy link
Member Author

commented Jan 20, 2018

I had wanted to finalize the 1.6.1 release today, but I think it's a bit late for that, especially given that 1.6.1-rc.10 just went out. Please give 1.6.1-rc.10 a try soon if you've been waiting for any of the recent fixes. Also remember that Meteor 1.6.2 is right around the corner!

benjamn added some commits Jan 20, 2018

@benjamn benjamn merged commit 6dd9134 into master Jan 20, 2018

13 checks passed

CLA Author has signed the Meteor CLA.
Details
ci/circleci: Get Ready Your tests passed on CircleCI!
Details
ci/circleci: Group 0 Your tests passed on CircleCI!
Details
ci/circleci: Group 1 Your tests passed on CircleCI!
Details
ci/circleci: Group 2 Your tests passed on CircleCI!
Details
ci/circleci: Group 3 Your tests passed on CircleCI!
Details
ci/circleci: Group 4 Your tests passed on CircleCI!
Details
ci/circleci: Group 5 Your tests passed on CircleCI!
Details
ci/circleci: Group 6 Your tests passed on CircleCI!
Details
ci/circleci: Group 7 Your tests passed on CircleCI!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@benjamn benjamn referenced this pull request Jan 21, 2018

Closed

Release 1.6.2 #9559

@p3pp8

This comment has been minimized.

Copy link

commented Jan 30, 2018

Hello, just a simple question: version 1.6.1 finally totally broke compatibility with static templates from urigo(it requires babel compiler 6.8.0), i'm seriously tired to try to find out some workaround as it seems that static templates is discontinued and unfortunately i'm not able to fix it my self, so, is there any way to substitute it and continue the development using angular 1.x.x without stepping forward to angular 2 or using balzeJS or something else? any suggestion is really appreciated!

@benjamn

This comment has been minimized.

Copy link
Member Author

commented Jan 30, 2018

@p3pp8 Please see the Atmosphere package version conflicts section of the 1.6.1 blog post, where we suggest cloning the package into your local packages/ directory and making its babel-compiler version constraint compatible with babel-compiler@7.0.0.

@p3pp8

This comment has been minimized.

Copy link

commented Jan 30, 2018

Thanx for the answer Benjamin, this is an easy solution!!!
I managed to build the updated local package. Anyway, i've found there was already a PR with a patched version of the source. We hope @Urigo will accept it!!!

@vladejs

This comment has been minimized.

Copy link

commented Feb 17, 2018

Hi, I just upgraded to 1.6.1. Not sure if this thread is still alive, but I'm getting issues regarding files stored in compatibility folder.

They are being treated as routes as I noticed on the server (via server-render package), that going to the app's root, it tried to load /compatibility/jquery.easing.js | other_file.js

@hwillson

This comment has been minimized.

Copy link
Member

commented Feb 19, 2018

@vladejs I'd recommend opening a new issue. Thanks!

benjamn added a commit that referenced this pull request May 12, 2018

@Slava

This comment has been minimized.

Copy link
Member

commented on 7268fb8 Jul 15, 2019

Interesting, I wonder why accessing process.env would be so much slower than seemingly an equivalent variable? As far as I know process.env is copied once in the beginning of node init and doesn't change/doesn't make any additional look-ups 馃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can鈥檛 perform that action at this time.