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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 1.0.2 #3285

Closed
glasser opened this Issue Dec 12, 2014 · 71 comments

Comments

Projects
None yet
@glasser
Member

glasser commented Dec 12, 2014

This issue tracks the release of Meteor 1.0.2. Have any concerns? Mention them here. Finding that the RCs are working great? Mention that here. We will keep this top-level description updated with known issues.

The current RC is 1.0.2-rc.7. Update your apps to the RC with meteor update --release 1.0.2-rc.7. If you had set the METEOR_OFFLINE_CATALOG environment variable previously in order to work around previous performance issues, please stop setting it.

The focus of this release is command-line tool performance and stability, plus the meteor shell command.

Known issues:

  • History.md rough draft: https://github.com/meteor/meteor/blob/release-1.0.2/History.md
  • History.md final draft
  • Still hoping to improve rebuild time for packages with npm deps #3279
  • Still hoping to remove self-test dependencies from the published tool [done in rc.6]
  • Cordova builds don't work [fixed in rc.2]
  • File change detection broken on Vagrant #3284 [partially fixed in rc.5 and rc.6, fully fixed in rc.7]
  • Reloads get slower over time? #2846 (comment)
  • TypeError: Cannot read property 'version' of undefined #3285 (comment) [Believed fixed in rc.4]
  • springboard does not refresh catalog if it knows about the release but not about the build. This is not a regression from 1.0. Workaround: 'meteor refresh' first. #3317
  • Too many *s in meteor list when running from prerelease. [not actually a bug]
  • safe-pathwatcher.testDirectory throws if .meteor/local does not exist yet [fixed in rc.6]
  • sessions fact can be negative: #3285 (comment) [no consistent reproduction]
  • client refresh when editing (but not saving) files in vim: #3322 [cannot reproduce]

RC history:

  • 1.0.2-rc.1: initial release candidate
  • 1.0.2-rc.2: fix failure to run Cordova builds
  • 1.0.2-rc.3: hopefully fix "Cannot read property 'version' of undefined" error
  • 1.0.2-rc.4: [mistakes made in the release process, DO NOT USE]
  • 1.0.2-rc.5: File watching should work on NFS, Vagrant shared folders, and other non-traditional filesystems. [Though not in a common Vagrant use case; will be fixed in a later RC.]
  • 1.0.2-rc.6:
    • pathwatcher improvements: work better under Vagrant; print a message at the debug level; more tests
    • clear various tokens on password change
    • more validation of update methods
    • remove self-test support from built tool (shrink size of tool download)
    • implement soft refresh (#3213); should stop reloads from getting slower over time
  • 1.0.2-rc.7: Pathwatcher finally should work on Vagrant vboxsf with no extra configuration. Also fix a typo in meteor login output.
@ManuelDeLeon

This comment has been minimized.

Show comment
Hide comment
@ManuelDeLeon

ManuelDeLeon Dec 12, 2014

I can't get a hello world to work with rc.2 =(

manuel@manuel-VirtualBox:~/temp$ meteor create addHelper
addHelper: created.                           

To run your new app:                          
   cd addHelper
   meteor
manuel@manuel-VirtualBox:~/temp$ cd addHelper 
manuel@manuel-VirtualBox:~/temp/addHelper$ meteor update --release 1.0.2-rc.2

Changes to your project's package version selections from updating the release:

application-configuration  upgraded from 1.0.3 to 1.0.4-rc.1
autopublish                upgraded from 1.0.1 to 1.0.2-rc.1
autoupdate                 upgraded from 1.1.3 to 1.1.4-rc.1
base64                     upgraded from 1.0.1 to 1.0.2-rc.1
binary-heap                upgraded from 1.0.1 to 1.0.2-rc.1
blaze                      upgraded from 2.0.3 to 2.0.4-rc.1
blaze-tools                upgraded from 1.0.1 to 1.0.2-rc.1
boilerplate-generator      upgraded from 1.0.1 to 1.0.2-rc.1
callback-hook              upgraded from 1.0.1 to 1.0.2-rc.1
check                      upgraded from 1.0.2 to 1.0.3-rc.1
ctl                        removed from your project
ctl-helper                 removed from your project
ddp                        upgraded from 1.0.12 to 1.0.13-rc.1
deps                       upgraded from 1.0.5 to 1.0.6-rc.1
ejson                      upgraded from 1.0.4 to 1.0.5-rc.1
fastclick                  upgraded from 1.0.1 to 1.0.2-rc.1
follower-livedata          upgraded from 1.0.2 to 1.0.3-rc.1
geojson-utils              upgraded from 1.0.1 to 1.0.2-rc.1
html-tools                 upgraded from 1.0.2 to 1.0.3-rc.1
htmljs                     upgraded from 1.0.2 to 1.0.3-rc.1
http                       upgraded from 1.0.8 to 1.0.9-rc.1
id-map                     upgraded from 1.0.1 to 1.0.2-rc.1
insecure                   upgraded from 1.0.1 to 1.0.2-rc.1
jquery                     upgraded from 1.0.1 to 1.0.2-rc.1
json                       upgraded from 1.0.1 to 1.0.2-rc.1
launch-screen              upgraded from 1.0.0 to 1.0.1-rc.1
livedata                   upgraded from 1.0.11 to 1.0.12-rc.1
logging                    upgraded from 1.0.5 to 1.0.6-rc.1
meteor                     upgraded from 1.1.3 to 1.1.4-rc.1
meteor-platform            upgraded from 1.2.0 to 1.2.1-rc.1
minifiers                  upgraded from 1.1.2 to 1.1.3-rc.1
minimongo                  upgraded from 1.0.5 to 1.0.6-rc.1
mobile-status-bar          upgraded from 1.0.1 to 1.0.2-rc.1
mongo                      upgraded from 1.0.9 to 1.0.10-rc.1
observe-sequence           upgraded from 1.0.3 to 1.0.4-rc.1
ordered-dict               upgraded from 1.0.1 to 1.0.2-rc.1
random                     upgraded from 1.0.1 to 1.0.2-rc.1
reactive-dict              upgraded from 1.0.4 to 1.0.5-rc.1
reactive-var               upgraded from 1.0.3 to 1.0.4-rc.1
reload                     upgraded from 1.1.1 to 1.1.2-rc.1
retry                      upgraded from 1.0.1 to 1.0.2-rc.1
routepolicy                upgraded from 1.0.2 to 1.0.3-rc.1
session                    upgraded from 1.0.4 to 1.0.5-rc.1
spacebars                  upgraded from 1.0.3 to 1.0.4-rc.1
spacebars-compiler         upgraded from 1.0.3 to 1.0.4-rc.1
templating                 upgraded from 1.0.9 to 1.0.10-rc.1
tracker                    upgraded from 1.0.3 to 1.0.4-rc.1
ui                         upgraded from 1.0.4 to 1.0.5-rc.1
underscore                 upgraded from 1.0.1 to 1.0.2-rc.1
url                        upgraded from 1.0.2 to 1.0.3-rc.1
webapp                     upgraded from 1.1.4 to 1.1.5-rc.1
webapp-hashing             upgraded from 1.0.1 to 1.0.2-rc.1

addHelper: updated to Meteor 1.0.2-rc.2.      
manuel@manuel-VirtualBox:~/temp/addHelper$ meteor
[[[[[ ~/temp/addHelper ]]]]]                  

=> Started proxy.                             

/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/dev_bundle/lib/node_modules/fibers/future.js:173
                        throw(ex);
                              ^
TypeError: Cannot read property 'version' of undefined
    at /home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/stats.js:27:20
    at /home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/package-map.js:43:7
    at Function._.each._.forEach (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/dev_bundle/lib/node_modules/underscore/underscore.js:87:22)
    at [object Object]._.extend.eachPackage (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/package-map.js:42:7)
    at packageList (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/stats.js:24:29)
    at Object.recordPackages (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/stats.js:44:18)
    at bundleApp (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/run-app.js:502:15)
    at [object Object]._.extend._runOnce (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/run-app.js:544:35)
    at [object Object]._.extend._fiber (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/run-app.js:759:28)
    at /home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/run-app.js:365:12

ManuelDeLeon commented Dec 12, 2014

I can't get a hello world to work with rc.2 =(

manuel@manuel-VirtualBox:~/temp$ meteor create addHelper
addHelper: created.                           

To run your new app:                          
   cd addHelper
   meteor
manuel@manuel-VirtualBox:~/temp$ cd addHelper 
manuel@manuel-VirtualBox:~/temp/addHelper$ meteor update --release 1.0.2-rc.2

Changes to your project's package version selections from updating the release:

application-configuration  upgraded from 1.0.3 to 1.0.4-rc.1
autopublish                upgraded from 1.0.1 to 1.0.2-rc.1
autoupdate                 upgraded from 1.1.3 to 1.1.4-rc.1
base64                     upgraded from 1.0.1 to 1.0.2-rc.1
binary-heap                upgraded from 1.0.1 to 1.0.2-rc.1
blaze                      upgraded from 2.0.3 to 2.0.4-rc.1
blaze-tools                upgraded from 1.0.1 to 1.0.2-rc.1
boilerplate-generator      upgraded from 1.0.1 to 1.0.2-rc.1
callback-hook              upgraded from 1.0.1 to 1.0.2-rc.1
check                      upgraded from 1.0.2 to 1.0.3-rc.1
ctl                        removed from your project
ctl-helper                 removed from your project
ddp                        upgraded from 1.0.12 to 1.0.13-rc.1
deps                       upgraded from 1.0.5 to 1.0.6-rc.1
ejson                      upgraded from 1.0.4 to 1.0.5-rc.1
fastclick                  upgraded from 1.0.1 to 1.0.2-rc.1
follower-livedata          upgraded from 1.0.2 to 1.0.3-rc.1
geojson-utils              upgraded from 1.0.1 to 1.0.2-rc.1
html-tools                 upgraded from 1.0.2 to 1.0.3-rc.1
htmljs                     upgraded from 1.0.2 to 1.0.3-rc.1
http                       upgraded from 1.0.8 to 1.0.9-rc.1
id-map                     upgraded from 1.0.1 to 1.0.2-rc.1
insecure                   upgraded from 1.0.1 to 1.0.2-rc.1
jquery                     upgraded from 1.0.1 to 1.0.2-rc.1
json                       upgraded from 1.0.1 to 1.0.2-rc.1
launch-screen              upgraded from 1.0.0 to 1.0.1-rc.1
livedata                   upgraded from 1.0.11 to 1.0.12-rc.1
logging                    upgraded from 1.0.5 to 1.0.6-rc.1
meteor                     upgraded from 1.1.3 to 1.1.4-rc.1
meteor-platform            upgraded from 1.2.0 to 1.2.1-rc.1
minifiers                  upgraded from 1.1.2 to 1.1.3-rc.1
minimongo                  upgraded from 1.0.5 to 1.0.6-rc.1
mobile-status-bar          upgraded from 1.0.1 to 1.0.2-rc.1
mongo                      upgraded from 1.0.9 to 1.0.10-rc.1
observe-sequence           upgraded from 1.0.3 to 1.0.4-rc.1
ordered-dict               upgraded from 1.0.1 to 1.0.2-rc.1
random                     upgraded from 1.0.1 to 1.0.2-rc.1
reactive-dict              upgraded from 1.0.4 to 1.0.5-rc.1
reactive-var               upgraded from 1.0.3 to 1.0.4-rc.1
reload                     upgraded from 1.1.1 to 1.1.2-rc.1
retry                      upgraded from 1.0.1 to 1.0.2-rc.1
routepolicy                upgraded from 1.0.2 to 1.0.3-rc.1
session                    upgraded from 1.0.4 to 1.0.5-rc.1
spacebars                  upgraded from 1.0.3 to 1.0.4-rc.1
spacebars-compiler         upgraded from 1.0.3 to 1.0.4-rc.1
templating                 upgraded from 1.0.9 to 1.0.10-rc.1
tracker                    upgraded from 1.0.3 to 1.0.4-rc.1
ui                         upgraded from 1.0.4 to 1.0.5-rc.1
underscore                 upgraded from 1.0.1 to 1.0.2-rc.1
url                        upgraded from 1.0.2 to 1.0.3-rc.1
webapp                     upgraded from 1.1.4 to 1.1.5-rc.1
webapp-hashing             upgraded from 1.0.1 to 1.0.2-rc.1

addHelper: updated to Meteor 1.0.2-rc.2.      
manuel@manuel-VirtualBox:~/temp/addHelper$ meteor
[[[[[ ~/temp/addHelper ]]]]]                  

=> Started proxy.                             

/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/dev_bundle/lib/node_modules/fibers/future.js:173
                        throw(ex);
                              ^
TypeError: Cannot read property 'version' of undefined
    at /home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/stats.js:27:20
    at /home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/package-map.js:43:7
    at Function._.each._.forEach (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/dev_bundle/lib/node_modules/underscore/underscore.js:87:22)
    at [object Object]._.extend.eachPackage (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/package-map.js:42:7)
    at packageList (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/stats.js:24:29)
    at Object.recordPackages (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/stats.js:44:18)
    at bundleApp (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/run-app.js:502:15)
    at [object Object]._.extend._runOnce (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/run-app.js:544:35)
    at [object Object]._.extend._fiber (/home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/run-app.js:759:28)
    at /home/manuel/.meteor/packages/meteor-tool/.1.0.37-rc.2.egpe90++os.linux.x86_32+web.browser+web.cordova/meteor-tool-os.linux.x86_32/tools/run-app.js:365:12
@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 12, 2014

Member

@ManuelDeLeon What OS are you on? @Slava noticed something similar on the windows branch. He has a fix but not one that makes any sense...

Member

glasser commented Dec 12, 2014

@ManuelDeLeon What OS are you on? @Slava noticed something similar on the windows branch. He has a fix but not one that makes any sense...

@ManuelDeLeon

This comment has been minimized.

Show comment
Hide comment
@ManuelDeLeon

ManuelDeLeon Dec 12, 2014

Lubuntu 14.04, I'll check on a regular Ubuntu box.

ManuelDeLeon commented Dec 12, 2014

Lubuntu 14.04, I'll check on a regular Ubuntu box.

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 12, 2014

Member

OK. I see "VirtualBox" there too --- are you in a VirtualBox shared folder? Does it work in a non-shared folder?

Member

glasser commented Dec 12, 2014

OK. I see "VirtualBox" there too --- are you in a VirtualBox shared folder? Does it work in a non-shared folder?

@ManuelDeLeon

This comment has been minimized.

Show comment
Hide comment
@ManuelDeLeon

ManuelDeLeon Dec 12, 2014

The issue is upgrading from rc.1 to rc.2. There's probably a problem with the upgrade routine.

Here's how to reproduce the issue:

# Remove Meteor
$ sudo rm /usr/local/bin/meteor
$ rm -rf ~/.meteor

# Install Meteor
$ curl https://install.meteor.com | /bin/sh

# Create a project
$ meteor create badOne
$ cd badOne

# Upgrade to rc.1
$ meteor update --release 1.0.2-rc.1

# Run Meteor (you'll get the rc.1 error)
$ meteor

# Upgrade to rc.2
$ meteor update --release 1.0.2-rc.2

# Run Meteor (you'll continue to get the error)
$ meteor

To fix it, remove Meteor, install it again, and update directly to rc.2. No errors then.

btw, I'm not using a shared folder and I get the same result in a good old Ubuntu box :)

ManuelDeLeon commented Dec 12, 2014

The issue is upgrading from rc.1 to rc.2. There's probably a problem with the upgrade routine.

Here's how to reproduce the issue:

# Remove Meteor
$ sudo rm /usr/local/bin/meteor
$ rm -rf ~/.meteor

# Install Meteor
$ curl https://install.meteor.com | /bin/sh

# Create a project
$ meteor create badOne
$ cd badOne

# Upgrade to rc.1
$ meteor update --release 1.0.2-rc.1

# Run Meteor (you'll get the rc.1 error)
$ meteor

# Upgrade to rc.2
$ meteor update --release 1.0.2-rc.2

# Run Meteor (you'll continue to get the error)
$ meteor

To fix it, remove Meteor, install it again, and update directly to rc.2. No errors then.

btw, I'm not using a shared folder and I get the same result in a good old Ubuntu box :)

@ManuelDeLeon

This comment has been minimized.

Show comment
Hide comment
@ManuelDeLeon

ManuelDeLeon Dec 12, 2014

There's no rest for the wicked. Just to try I removed Meteor, installed it again, created a project, upgraded directly to rc.2 and got the error again. I then re-installed Meteor, ran the project which was already upgraded to rc.2 (it downloaded the update), and this time it worked.

No clue what's going on.

ManuelDeLeon commented Dec 12, 2014

There's no rest for the wicked. Just to try I removed Meteor, installed it again, created a project, upgraded directly to rc.2 and got the error again. I then re-installed Meteor, ran the project which was already upgraded to rc.2 (it downloaded the update), and this time it worked.

No clue what's going on.

@jamgold

This comment has been minimized.

Show comment
Hide comment
@jamgold

jamgold Dec 12, 2014

Contributor

Works as advertised on OSX 10.10.1

Update: whenever I start the server under 1.0.2-rc2 it prints

warning: still trying to confirm logout with www.meteor.com
Contributor

jamgold commented Dec 12, 2014

Works as advertised on OSX 10.10.1

Update: whenever I start the server under 1.0.2-rc2 it prints

warning: still trying to confirm logout with www.meteor.com
@lirbank

This comment has been minimized.

Show comment
Hide comment
@lirbank

lirbank Dec 12, 2014

Just upgraded one of my projects to RC2. Works well with fast updates. I'm on OS X 10.10.1 (14B25).

lirbank commented Dec 12, 2014

Just upgraded one of my projects to RC2. Works well with fast updates. I'm on OS X 10.10.1 (14B25).

glasser added a commit that referenced this issue Dec 13, 2014

"Fix" bizarre memory corruption (?) bug
See #3285.  For some reason, in some mostly-replicatable circumstances,
this is necessary.  Clearly some sort of V8/Node/Fibers bug.
@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser
Member

glasser commented Dec 13, 2014

I've added a rough draft of History.md: https://github.com/meteor/meteor/blob/release-1.0.2/History.md

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 13, 2014

Member

I've just published 1.0.2-rc.3. @ManuelDeLeon Can you see if it fixes your issue? It seems to have resolved it for me, though I think we're triggering some underlying V8/Node/Fibers bug.

Member

glasser commented Dec 13, 2014

I've just published 1.0.2-rc.3. @ManuelDeLeon Can you see if it fixes your issue? It seems to have resolved it for me, though I think we're triggering some underlying V8/Node/Fibers bug.

@ManuelDeLeon

This comment has been minimized.

Show comment
Hide comment
@ManuelDeLeon

ManuelDeLeon Dec 13, 2014

Success! It works if I upgrade directly to rc.3 and also if I install rc.1 and then upgrade to rc.3.

ManuelDeLeon commented Dec 13, 2014

Success! It works if I upgrade directly to rc.3 and also if I install rc.1 and then upgrade to rc.3.

@PEM--

This comment has been minimized.

Show comment
Hide comment
@PEM--

PEM-- Dec 13, 2014

We have been using it all day long for rebuilding Meteor's Paris. It worked like a charm. 👏

PEM-- commented Dec 13, 2014

We have been using it all day long for rebuilding Meteor's Paris. It worked like a charm. 👏

@LarsBuur

This comment has been minimized.

Show comment
Hide comment
@LarsBuur

LarsBuur Dec 14, 2014

just updated the project we are working on to rc.3 without any problems and the rebuilding seems quicker when changing sourcefiles.

One strange note and one question:

meteor list reports that most of the core packages are ready to be updated with a star like so:

accounts-base                1.1.3-rc.1* A user account system
accounts-facebook            1.0.3-rc.1* Login service for Facebook accounts
accounts-google              1.0.3-rc.1* Login service for Google accounts
accounts-password            1.0.5-rc.1* Password support for accounts

but running "meteor update" reports:

This project is already at Meteor 1.0.2-rc.3, which is newer
than the latest release.
  added ctl at version 1.0.3-rc.1
  added ctl-helper at version 1.0.5-rc.1

each time I run it and the packages stays in rc.1.

The question is: There is a new + sign after some of the package version like so:

percolate:momentum           0.5.2+ Reactive animations

What does this mean?

Best regards
Lars Buur (on osx 10.10.1 14B25)

LarsBuur commented Dec 14, 2014

just updated the project we are working on to rc.3 without any problems and the rebuilding seems quicker when changing sourcefiles.

One strange note and one question:

meteor list reports that most of the core packages are ready to be updated with a star like so:

accounts-base                1.1.3-rc.1* A user account system
accounts-facebook            1.0.3-rc.1* Login service for Facebook accounts
accounts-google              1.0.3-rc.1* Login service for Google accounts
accounts-password            1.0.5-rc.1* Password support for accounts

but running "meteor update" reports:

This project is already at Meteor 1.0.2-rc.3, which is newer
than the latest release.
  added ctl at version 1.0.3-rc.1
  added ctl-helper at version 1.0.5-rc.1

each time I run it and the packages stays in rc.1.

The question is: There is a new + sign after some of the package version like so:

percolate:momentum           0.5.2+ Reactive animations

What does this mean?

Best regards
Lars Buur (on osx 10.10.1 14B25)

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 14, 2014

Member

@LarsBuur does it not print an explanation for the + at the bottom?

Member

glasser commented Dec 14, 2014

@LarsBuur does it not print an explanation for the + at the bottom?

@LarsBuur

This comment has been minimized.

Show comment
Hide comment
@LarsBuur

LarsBuur Dec 14, 2014

It does :-)

LarsBuur commented Dec 14, 2014

It does :-)

@neoromantic

This comment has been minimized.

Show comment
Hide comment
@neoromantic

neoromantic Dec 15, 2014

Am I stupid or what?

meteor update --release 1.0.2-rc.3
Meteor 1.0.2-rc.3: unknown release.

I've tried various approaches and nothing worked. What am I doing wrong?

neoromantic commented Dec 15, 2014

Am I stupid or what?

meteor update --release 1.0.2-rc.3
Meteor 1.0.2-rc.3: unknown release.

I've tried various approaches and nothing worked. What am I doing wrong?

@LarsBuur

This comment has been minimized.

Show comment
Hide comment
@LarsBuur

LarsBuur Dec 15, 2014

meteor update --release 1.0.2-rc.3 works for me.

LarsBuur commented Dec 15, 2014

meteor update --release 1.0.2-rc.3 works for me.

@jamgold

This comment has been minimized.

Show comment
Hide comment
@jamgold

jamgold Dec 15, 2014

Contributor

@neoromantic do you still have the environment variable METEOR_OFFLINE_CATALOG set?

Contributor

jamgold commented Dec 15, 2014

@neoromantic do you still have the environment variable METEOR_OFFLINE_CATALOG set?

@neoromantic

This comment has been minimized.

Show comment
Hide comment
@neoromantic

neoromantic Dec 15, 2014

@jamgold ok, so this is settled: I am stupid :) Yes, it was set. Thanks. :)

neoromantic commented Dec 15, 2014

@jamgold ok, so this is settled: I am stupid :) Yes, it was set. Thanks. :)

@lirbank

This comment has been minimized.

Show comment
Hide comment
@lirbank

lirbank Dec 15, 2014

@glasser - this (RC3) is so much faster than before! Even server-side code re-build and push to the clients quickly, which used to take a while. It takes a few seconds to rebuild the app, which is totally fine, and then it takes less than a split second to update the clients (I have multiple clients on different devices running). All in all, it's a breeze to work with!

lirbank commented Dec 15, 2014

@glasser - this (RC3) is so much faster than before! Even server-side code re-build and push to the clients quickly, which used to take a while. It takes a few seconds to rebuild the app, which is totally fine, and then it takes less than a split second to update the clients (I have multiple clients on different devices running). All in all, it's a breeze to work with!

@tmeasday

This comment has been minimized.

Show comment
Hide comment
@tmeasday

tmeasday Dec 15, 2014

Contributor

Way faster for Verso with no problems observed as yet (1 day of usage).

Contributor

tmeasday commented Dec 15, 2014

Way faster for Verso with no problems observed as yet (1 day of usage).

@dandv

This comment has been minimized.

Show comment
Hide comment
@dandv

dandv Dec 15, 2014

Contributor
$ meteor update --release 1.0.2-rc.3
Installed. Run 'meteor update' inside of a particular project directory to update that project to Meteor 1.0.2-rc.3.
$ cd modios
~/modios$ meteor update
This project is already at Meteor 1.0.2-rc.1, which is newer than the latest release.

Is this expected?

Contributor

dandv commented Dec 15, 2014

$ meteor update --release 1.0.2-rc.3
Installed. Run 'meteor update' inside of a particular project directory to update that project to Meteor 1.0.2-rc.3.
$ cd modios
~/modios$ meteor update
This project is already at Meteor 1.0.2-rc.1, which is newer than the latest release.

Is this expected?

glasser added a commit that referenced this issue Dec 16, 2014

"Fix" bizarre memory corruption (?) bug
See #3285.  For some reason, in some mostly-replicatable circumstances,
this is necessary.  Clearly some sort of V8/Node/Fibers bug.
@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 16, 2014

Member

@dandv It is; the latest release is 1.0.1, and 1.0.2-rc.1 is later than 1.0.1.

I guess the message is a little misleading though. Fixed in e8bef27.

Member

glasser commented Dec 16, 2014

@dandv It is; the latest release is 1.0.1, and 1.0.2-rc.1 is later than 1.0.1.

I guess the message is a little misleading though. Fixed in e8bef27.

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 16, 2014

Member

Also, re the *s reported by @LarsBuur : it's a little confusing, but this is accurate. There are "newer" versions of most of these packages, because the experimental Windows project has published packages with versions like 1.0.2-win.0, which are newer than 1.0.2-rc.1. See eg:

$ meteor show autopublish 
Package autopublish:

Version 0.0.0-glasser-isopacket.0  Publish the entire database to all clients
Version 1.0.0                      Publish the entire database to all clients
Version 1.0.1-pre.0                Publish the entire database to all clients
Version 1.0.1-pre.1                Publish the entire database to all clients
Version 1.0.1-pre.2                Publish the entire database to all clients
Version 1.0.1-rc.0                 Publish the entire database to all clients
Version 1.0.1-win.0                Publish the entire database to all clients
Version 1.0.1                      Publish the entire database to all clients
Version 1.0.2-ipc.0                Publish the entire database to all clients
Version 1.0.2-rc.1                 Publish the entire database to all clients
Version 1.0.2-win.0                Publish the entire database to all clients

(Normally meteor list only cares about "mainline" versions (those without dashes) when deciding if there are newer versions to recommend, but since you're already on an RC version it thinks that the win one is interesting!)

Member

glasser commented Dec 16, 2014

Also, re the *s reported by @LarsBuur : it's a little confusing, but this is accurate. There are "newer" versions of most of these packages, because the experimental Windows project has published packages with versions like 1.0.2-win.0, which are newer than 1.0.2-rc.1. See eg:

$ meteor show autopublish 
Package autopublish:

Version 0.0.0-glasser-isopacket.0  Publish the entire database to all clients
Version 1.0.0                      Publish the entire database to all clients
Version 1.0.1-pre.0                Publish the entire database to all clients
Version 1.0.1-pre.1                Publish the entire database to all clients
Version 1.0.1-pre.2                Publish the entire database to all clients
Version 1.0.1-rc.0                 Publish the entire database to all clients
Version 1.0.1-win.0                Publish the entire database to all clients
Version 1.0.1                      Publish the entire database to all clients
Version 1.0.2-ipc.0                Publish the entire database to all clients
Version 1.0.2-rc.1                 Publish the entire database to all clients
Version 1.0.2-win.0                Publish the entire database to all clients

(Normally meteor list only cares about "mainline" versions (those without dashes) when deciding if there are newer versions to recommend, but since you're already on an RC version it thinks that the win one is interesting!)

@timhaines

This comment has been minimized.

Show comment
Hide comment
@timhaines

timhaines Dec 16, 2014

Contributor

@glasser, just wanted to mention what you're doing with this issue is awesome. Both the working list of known issues, and the RC History are very helpful. Thank you.

Contributor

timhaines commented Dec 16, 2014

@glasser, just wanted to mention what you're doing with this issue is awesome. Both the working list of known issues, and the RC History are very helpful. Thank you.

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 17, 2014

Member

@dandv Can you provide much more detailed step by step instructions (a full reproduction) for seeing this?

Member

glasser commented Dec 17, 2014

@dandv Can you provide much more detailed step by step instructions (a full reproduction) for seeing this?

@timothyarmes

This comment has been minimized.

Show comment
Hide comment
@timothyarmes

timothyarmes Dec 17, 2014

@glasser Thanks. I'll let you know if you've fixed the issues once you've released the RC.

timothyarmes commented Dec 17, 2014

@glasser Thanks. I'll let you know if you've fixed the issues once you've released the RC.

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 17, 2014

Member

1.0.2-rc.6 is out, fixing a variety of issues (listed above).

@benjamn unfortunately, when I test rc 6 on Vagrant, it still doesn't work. It looks to me like if the action is performed inside the VM, then it does show up on inotify; it just doesn't show up if the action is performed outside the VM (and synced inside). So the test done by safe-pathwatcher ends up being a false positive. In this case, I'm really not sure that there's anything along the lines of a probe that we can do. Maybe we really do need to just document the environment variable. Can you figure out if there's any other way to detect Vagrant? Note that my testing is based on the instructions at https://gist.github.com/gabrielhpugliese/5855677

Member

glasser commented Dec 17, 2014

1.0.2-rc.6 is out, fixing a variety of issues (listed above).

@benjamn unfortunately, when I test rc 6 on Vagrant, it still doesn't work. It looks to me like if the action is performed inside the VM, then it does show up on inotify; it just doesn't show up if the action is performed outside the VM (and synced inside). So the test done by safe-pathwatcher ends up being a false positive. In this case, I'm really not sure that there's anything along the lines of a probe that we can do. Maybe we really do need to just document the environment variable. Can you figure out if there's any other way to detect Vagrant? Note that my testing is based on the instructions at https://gist.github.com/gabrielhpugliese/5855677

benjamn added a commit that referenced this issue Dec 17, 2014

Use both pathwatcher and polling to detect changes more robustly.
This strategy was suggested by @glasser after we realized just how
hopeless it is to probe the file system to test pathwatcher:
#3285 (comment)

I've made some attempt to de-duplicate these events (since we're
effectively watching twice now), but we have other mechanisms for dealing
with bursty file change events, so these measures do not need to be
completely bulletproof.

Fixes #3284 (again).
@dan335

This comment has been minimized.

Show comment
Hide comment
@dan335

dan335 Dec 17, 2014

I've noticed sessions from the facts package is sometimes negative. Never saw this before upgrading to 1.0.2 rc. It could be something I've change though.

image

dan335 commented Dec 17, 2014

I've noticed sessions from the facts package is sometimes negative. Never saw this before upgrading to 1.0.2 rc. It could be something I've change though.

image

benjamn added a commit that referenced this issue Dec 17, 2014

Use both pathwatcher and polling to detect changes more robustly.
This strategy was suggested by @glasser after we realized just how
hopeless it is to probe the file system to test pathwatcher:
#3285 (comment)

I've made some attempt to de-duplicate these events (since we're
effectively watching twice now), but we have other mechanisms for dealing
with bursty file change events, so these measures do not need to be
completely bulletproof.

Fixes #3284 (again).
@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 17, 2014

Member

@dan335 Huh. That's pretty odd. Is this in development or in production? Is there an easy way to consistently reproduce this? Do you see any odd stack traces in your logs? Can you try to reproduce it with 1.0.1 too? I don't think we've changed any relevant code.

I am reasonably confident that we can only decrement the number once per Session object. It's conceivable that the Session constructor throws before getting to its increment at the bottom of the constructor, but I don't actually see how likely that is.

Member

glasser commented Dec 17, 2014

@dan335 Huh. That's pretty odd. Is this in development or in production? Is there an easy way to consistently reproduce this? Do you see any odd stack traces in your logs? Can you try to reproduce it with 1.0.1 too? I don't think we've changed any relevant code.

I am reasonably confident that we can only decrement the number once per Session object. It's conceivable that the Session constructor throws before getting to its increment at the bottom of the constructor, but I don't actually see how likely that is.

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 17, 2014

Member

1.0.2-rc.7 is out! We think we've finally gotten file watching working efficiently and consistently under Vagrant/vboxsf and other network/virtual filesystems. Filesystems that don't support inotify/kevent will still detect file changes out of the box, though it may take up to 5 seconds to notice the changes. Setting the METEOR_WATCH_FORCE_POLLING environment variable will make it notice the changes faster, though with higher CPU usage than it takes out of the box on filesystems that support inotify/kevent.

The only other outstanding possible regression I know about is @dan335 's comment above, which I've been unable to reproduce. Test this one, folks --- it might be the last!

Member

glasser commented Dec 17, 2014

1.0.2-rc.7 is out! We think we've finally gotten file watching working efficiently and consistently under Vagrant/vboxsf and other network/virtual filesystems. Filesystems that don't support inotify/kevent will still detect file changes out of the box, though it may take up to 5 seconds to notice the changes. Setting the METEOR_WATCH_FORCE_POLLING environment variable will make it notice the changes faster, though with higher CPU usage than it takes out of the box on filesystems that support inotify/kevent.

The only other outstanding possible regression I know about is @dan335 's comment above, which I've been unable to reproduce. Test this one, folks --- it might be the last!

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 17, 2014

Member

@timothyarmes Also still curious if you're seeing decreasing performance over time with 1.0.2-rc.7!

Member

glasser commented Dec 17, 2014

@timothyarmes Also still curious if you're seeing decreasing performance over time with 1.0.2-rc.7!

@PEM--

This comment has been minimized.

Show comment
Hide comment
@PEM--

PEM-- Dec 17, 2014

I've seen that with the 1.0.2-rc.6. Usually, I'm forced to stop/restart my local server around 30 refresh. I didn't track the problem for the moment.

This is not a regression. This behavior was also happening with the former releases. I will check with the 1.0.2-rc.7. Tomorrow is dedicated to development. I will keep you posted.

PEM-- commented Dec 17, 2014

I've seen that with the 1.0.2-rc.6. Usually, I'm forced to stop/restart my local server around 30 refresh. I didn't track the problem for the moment.

This is not a regression. This behavior was also happening with the former releases. I will check with the 1.0.2-rc.7. Tomorrow is dedicated to development. I will keep you posted.

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 17, 2014

Member

@PEM-- "that" being increasingly slow rebuilds?

Does that occur for any file changes (eg, file changes directly in your app, not in packages)? I know of a leak that could cause this if the files you are changing are in a package with a plugin (or a package included in a plugin) but that particular leak shouldn't occur when editing files in your app.

Member

glasser commented Dec 17, 2014

@PEM-- "that" being increasingly slow rebuilds?

Does that occur for any file changes (eg, file changes directly in your app, not in packages)? I know of a leak that could cause this if the files you are changing are in a package with a plugin (or a package included in a plugin) but that particular leak shouldn't occur when editing files in your app.

@timothyarmes

This comment has been minimized.

Show comment
Hide comment
@timothyarmes

timothyarmes Dec 17, 2014

I concur with @pem - I still need to force kill the app (r6) after 20-30 changes. It suddenly becomes unresponsive.

timothyarmes commented Dec 17, 2014

I concur with @pem - I still need to force kill the app (r6) after 20-30 changes. It suddenly becomes unresponsive.

@PEM--

This comment has been minimized.

Show comment
Hide comment
@PEM--

PEM-- Dec 17, 2014

Hum... not an easy problem to solve. I was indeed modifying some of my packages at the same time that I was writing a customer app. When the package will get ready, I will focus on the customer app itself. I should be able to tell you if there is a difference in the 'slowing down rebuild'.

@timothyarmes, Were you modifying a package when you see the 'slowing down rebuild' issue?

PEM-- commented Dec 17, 2014

Hum... not an easy problem to solve. I was indeed modifying some of my packages at the same time that I was writing a customer app. When the package will get ready, I will focus on the customer app itself. I should be able to tell you if there is a difference in the 'slowing down rebuild'.

@timothyarmes, Were you modifying a package when you see the 'slowing down rebuild' issue?

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 17, 2014

Member

Hmm, that's frustrating. I am not observing a slowdown after hundreds of modifications to a server file in localmarket, but maybe there's something different about that app than others. I'll try on a larger benchmark app too. But the more details the better...

Member

glasser commented Dec 17, 2014

Hmm, that's frustrating. I am not observing a slowdown after hundreds of modifications to a server file in localmarket, but maybe there's something different about that app than others. I'll try on a larger benchmark app too. But the more details the better...

@PEM--

This comment has been minimized.

Show comment
Hide comment
@PEM--

PEM-- Dec 18, 2014

@glasser I was doing a lot of front lately... That could explain the fact that you did not see these 'slowing down rebuilds'. Localmarket should be a good candidate if you torture it only on the front part.

PEM-- commented Dec 18, 2014

@glasser I was doing a lot of front lately... That could explain the fact that you did not see these 'slowing down rebuilds'. Localmarket should be a good candidate if you torture it only on the front part.

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 18, 2014

Member

I've modified client/head.html 50 times with no effect on the rebuild time (about 1.5s). I would love to ensure that 1.0.2 (or at least a future release, if this isn't fixed today) doesn't have this problem, so any more details about how to trigger the slowdown would be appreciated (including access to your app source if that's something you're comfortable with).

Member

glasser commented Dec 18, 2014

I've modified client/head.html 50 times with no effect on the rebuild time (about 1.5s). I would love to ensure that 1.0.2 (or at least a future release, if this isn't fixed today) doesn't have this problem, so any more details about how to trigger the slowdown would be appreciated (including access to your app source if that's something you're comfortable with).

@PEM--

This comment has been minimized.

Show comment
Hide comment
@PEM--

PEM-- Dec 18, 2014

No problem for the source access. I've set it up here:

If I find exactly a reproduction pattern, I will describe you exactly what I did.

PEM-- commented Dec 18, 2014

No problem for the source access. I've set it up here:

If I find exactly a reproduction pattern, I will describe you exactly what I did.

@timothyarmes

This comment has been minimized.

Show comment
Hide comment
@timothyarmes

timothyarmes Dec 18, 2014

For info, I'm not modifying any packages.

timothyarmes commented Dec 18, 2014

For info, I'm not modifying any packages.

@robfallows

This comment has been minimized.

Show comment
Hide comment
@robfallows

robfallows Dec 18, 2014

Contributor

I'm seeing lots of client refreshes when opening and editing css files (i.e. before saving changes). It seems to "see" the vim .name.swp file as something to track (this may have been in previous releases - I've only just noticed it).

Otherwise, the speed of refresh, particularly on server code is way better than 1.0.1 - It's taking about 1/10 the time it used to. Nice work!

Contributor

robfallows commented Dec 18, 2014

I'm seeing lots of client refreshes when opening and editing css files (i.e. before saving changes). It seems to "see" the vim .name.swp file as something to track (this may have been in previous releases - I've only just noticed it).

Otherwise, the speed of refresh, particularly on server code is way better than 1.0.1 - It's taking about 1/10 the time it used to. Nice work!

@jamgold

This comment has been minimized.

Show comment
Hide comment
@jamgold

jamgold Dec 18, 2014

Contributor

@robfallows maybe you should set your backup directory for vim to point outside of the meteor app directory

# $HOME/.vimrc
:set directory=$HOME/.vim/swapfiles//
Contributor

jamgold commented Dec 18, 2014

@robfallows maybe you should set your backup directory for vim to point outside of the meteor app directory

# $HOME/.vimrc
:set directory=$HOME/.vim/swapfiles//
@PEM--

This comment has been minimized.

Show comment
Hide comment
@PEM--

PEM-- Dec 18, 2014

@glasser So far, 67 rebuilds doing packages and front, no slowing down on the 1.0.2.rc.7.

PEM-- commented Dec 18, 2014

@glasser So far, 67 rebuilds doing packages and front, no slowing down on the 1.0.2.rc.7.

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 18, 2014

Member

@robfallows Can you provide more detailed instructions on how to reproduce this? Can you reproduce this in, eg, a brand new meteor created app? What file are you editing in what directory? What OS are you on? I can't reproduce this with editing (and not saving) the CSS file in the default meteor created app on OSX.

Member

glasser commented Dec 18, 2014

@robfallows Can you provide more detailed instructions on how to reproduce this? Can you reproduce this in, eg, a brand new meteor created app? What file are you editing in what directory? What OS are you on? I can't reproduce this with editing (and not saving) the CSS file in the default meteor created app on OSX.

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 18, 2014

Member

@robfallows I can reproduce this with editing files in the public directory, but that does not appear to be a regression vs 1.0.1. (In the public directory we rebuild on ANY file change except those in bundler.ignoreFiles, and I guess we don't have an ignore regexp for vim backup files. But in the normal source directories we only watch for files of known source code extensions.

Member

glasser commented Dec 18, 2014

@robfallows I can reproduce this with editing files in the public directory, but that does not appear to be a regression vs 1.0.1. (In the public directory we rebuild on ANY file change except those in bundler.ignoreFiles, and I guess we don't have an ignore regexp for vim backup files. But in the normal source directories we only watch for files of known source code extensions.

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 19, 2014

Member

Meteor 1.0.2 is out! All remaining confirmed known issues are now in their own bugs.

blog post: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
release notes: https://github.com/meteor/meteor/blob/devel/History.md

Thanks for helping stabilize Meteor 1.0.2! I hope people liked this GitHub-based process for release stabilization.

Member

glasser commented Dec 19, 2014

Meteor 1.0.2 is out! All remaining confirmed known issues are now in their own bugs.

blog post: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
release notes: https://github.com/meteor/meteor/blob/devel/History.md

Thanks for helping stabilize Meteor 1.0.2! I hope people liked this GitHub-based process for release stabilization.

@glasser glasser closed this Dec 19, 2014

@dandv

This comment has been minimized.

Show comment
Hide comment
@dandv

dandv Dec 19, 2014

Contributor

Nice! The blog post took about 40 seconds to load though... hopefully it's the traffic!

Contributor

dandv commented Dec 19, 2014

Nice! The blog post took about 40 seconds to load though... hopefully it's the traffic!

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Dec 22, 2014

Member

Dear folks who helped test 1.0.2: I'm readying a small patch release which fixes a few small issues in 1.0.2! I'd appreciate as much testing as possible, since I'm trying to release as soon as possible. It is being tracked in #3338.

Member

glasser commented Dec 22, 2014

Dear folks who helped test 1.0.2: I'm readying a small patch release which fixes a few small issues in 1.0.2! I'd appreciate as much testing as possible, since I'm trying to release as soon as possible. It is being tracked in #3338.

@jhorn3

This comment has been minimized.

Show comment
Hide comment
@jhorn3

jhorn3 Jul 13, 2015

How do you unset METEOR_OFFLINE_CATALOG if it says "unset" isn't a command?

jhorn3 commented Jul 13, 2015

How do you unset METEOR_OFFLINE_CATALOG if it says "unset" isn't a command?

@Slava

This comment has been minimized.

Show comment
Hide comment
@Slava

Slava Jul 13, 2015

Member

@jhorn3 unset is a command in bash. This might work differently depending on the shell you are using. If you are using some non-standard shell (like fish-shell, for example), look at the shell's docs.

Member

Slava commented Jul 13, 2015

@jhorn3 unset is a command in bash. This might work differently depending on the shell you are using. If you are using some non-standard shell (like fish-shell, for example), look at the shell's docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment