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’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
Closed

Release 1.0.2 #3285

glasser opened this issue Dec 12, 2014 · 71 comments
Assignees

Comments

@glasser
Copy link
Member

@glasser 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
Copy link

@ManuelDeLeon 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
Copy link
Member Author

@glasser 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
Copy link

@ManuelDeLeon ManuelDeLeon commented Dec 12, 2014

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

@glasser
Copy link
Member Author

@glasser 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
Copy link

@ManuelDeLeon 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
Copy link

@ManuelDeLeon 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
Copy link
Contributor

@jamgold 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
Copy link

@lirbank 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
See #3285.  For some reason, in some mostly-replicatable circumstances,
this is necessary.  Clearly some sort of V8/Node/Fibers bug.
@glasser
Copy link
Member Author

@glasser 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
Copy link
Member Author

@glasser 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
Copy link

@ManuelDeLeon 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--
Copy link

@PEM-- PEM-- commented Dec 13, 2014

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

@LarsBuur
Copy link

@LarsBuur 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
Copy link
Member Author

@glasser glasser commented Dec 14, 2014

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

@LarsBuur
Copy link

@LarsBuur LarsBuur commented Dec 14, 2014

It does :-)

@neoromantic
Copy link

@neoromantic 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
Copy link

@LarsBuur LarsBuur commented Dec 15, 2014

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

@jamgold
Copy link
Contributor

@jamgold jamgold commented Dec 15, 2014

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

@neoromantic
Copy link

@neoromantic neoromantic commented Dec 15, 2014

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

@lirbank
Copy link

@lirbank 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
Copy link
Contributor

@tmeasday tmeasday commented Dec 15, 2014

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

@dandv
Copy link
Contributor

@dandv 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
See #3285.  For some reason, in some mostly-replicatable circumstances,
this is necessary.  Clearly some sort of V8/Node/Fibers bug.
@glasser
Copy link
Member Author

@glasser 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
Copy link
Member Author

@glasser 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
Copy link
Contributor

@timhaines 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
Copy link
Member Author

@glasser glasser commented Dec 17, 2014

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

@timothyarmes
Copy link

@timothyarmes 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
Copy link
Member Author

@glasser 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
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
Copy link

@dan335 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
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
Copy link
Member Author

@glasser 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
Copy link
Member Author

@glasser 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
Copy link
Member Author

@glasser glasser commented Dec 17, 2014

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

@PEM--
Copy link

@PEM-- 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
Copy link
Member Author

@glasser 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
Copy link

@timothyarmes 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--
Copy link

@PEM-- 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
Copy link
Member Author

@glasser 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--
Copy link

@PEM-- 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
Copy link
Member Author

@glasser 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--
Copy link

@PEM-- 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
Copy link

@timothyarmes timothyarmes commented Dec 18, 2014

For info, I'm not modifying any packages.

@robfallows
Copy link
Contributor

@robfallows 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
Copy link
Contributor

@jamgold 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--
Copy link

@PEM-- 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
Copy link
Member Author

@glasser 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
Copy link
Member Author

@glasser 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
Copy link
Member Author

@glasser 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
Copy link
Contributor

@dandv dandv commented Dec 19, 2014

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

@glasser
Copy link
Member Author

@glasser 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
Copy link

@jhorn3 jhorn3 commented Jul 13, 2015

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

@Slava
Copy link
Member

@Slava 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.