how to not auto-update meteor

[Daniel Radetsky]

started my proj, and meteor says it is auto-updating me to 0.9.0 and removing old versions. I'm trying to do a release this morning and can't deal with upgrading bullshit today. Is there a way to prevent upgrading and stick with 0.8.3 for the time being? Please advise.

[Andrew Mao]

It'll put the old versions back after removing them. Glasser just put that in to scare us.

[Daniel Radetsky]

So not to infuriate us? Because he's pulled that one off nicely.

[Bernardo Kuri]

No kidding... My current project is completely borked after this auto installation process. At least 4 of the addons I'm using are incompatible with 0.9 and now I'm posting github issues all over the place.

Auto updates are always a bad idea.

[Andrew Mao]

Oh yeah, to infuriate us too: https://github.com/meteor/meteor/issues/2443

[Daniel Radetsky]

Our project is too. We used packages with capital letters in them, which apparently doesn't work anymore. SlickGrid, Crossfilter, etc. Also, airbrake.io isn't working for some reason. 

NEVER DO THIS SHIT AGAIN. 

Seriously, what were you thinking? Just because it's easy to buy crack near the Meteor office doesn't mean you have to smoke any. Just say no.

[Andrew Mao]

Your project should still be runnable on Meteor 0.8.3. Don't run it on 0.9.

[Daniel Radetsky]

I understand, but you should still take out the auto-upgrade ASAFP

[David Glasser]

We're a small team moving rapidly towards 1.0.  In order to make issues feasible to debug, we want to keep complexity down.

It's already complex enough to maintain the system that we did release, where we maintain full backwards compatibility for users running 0.8.3 and older apps after 0.9.0 is installed.  Making a system where the top-level runner script could be one of two different platforms would be a lot more complicated and will lead to more bugs.

If you're encountering issues where, after 0.9.0 is installed and your older release is re-downloaded, there is any difficulty continuing to use 0.8.3, please file a bug.  We put a lot of time and energy into enabling exactly this use case when we could have just said "You're using pre-1.0 software, you have to port your apps to 0.9.0 immediately".  All our tests so far show that this mode works, so please report any bugs in it.

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Radetsky]

I don't understand why it isn't simpler to not automatically upgrade than to automatically upgrade.

[Daniel Radetsky]

In any case, you've fucked up our release schedule.

[David Greenspan]

I think Andrew and David Glasser are implying that Meteor doesn't actually force-update you to 0.9.0.  If so, maybe this is just a misunderstanding.

-- David

[Mitar]

Hi!

Could you provide a install-0.8.meteor.com script which installs
Meteor 0.8.3 and it keeps it that way?


Mitar

http://mitar.tnode.com/
https://twitter.com/mitar_m

[David Glasser]

Mitar, that sounds like a great workaround we can do if we receive any bug reports of people being unable to run their Meteor 0.8 apps through the 0.9 wrapper. We haven't heard any such bug reports yet, so I don't see any reason to run that additional infrastructure!

[David Greenspan]

To be clear, the new release is not a "forced update" -- it does not force you to update your apps to 0.9.0.  You can still run your 0.8.3 apps and packages without upgrading them to work with 0.9.0.

-- David

On Tue, Aug 26, 2014 at 2:44 PM, Mitar <mmi...@gmail.com> wrote:

[Mitar]

Hi!

The thing which does force you is removal of .meteor/tools/latest/bin
directory which was before available, and now is not anymore.


Mitar

[Daniel Radetsky]

Fun fact: If you tell a unix user that the program he's running is about to be automatically upgraded to a version he doesn't want, he often responds by pressing Ctrl-C. If the system is halfway through changing his install around, it may be left in a state which cannot be run or upgraded. However, it may also not be obvious that the system can no longer be run or upgraded. So the user might spend a lot of time being confused. This happened to one of my developers this morning.

I hasten to mention that there is a very solution to this problem, which involves EVEN LESS engineering effort than implementing an automatic upgrade. Discovering this solution is left as an exercise for the reader.

[Andrew Mao]

I was also a victim of the Ctrl-C :)

[Mitar]

Hi!

Can you continue allowing access to bootstrap? This does not seem to
work for me?

https://d3sqy0vbqsdhku.cloudfront.net/packages-bootstrap/os.linux.x86_64/meteor-bootstrap-0.8.3.tar.gz


Mitar

[Mitar]

Hi!

Or at least if somebody can give me those files for all platforms and
I can host them myself.



Mitar

[Mitar]

Hi!

Found it:

https://warehouse.meteor.com/bootstrap/0.8.3/meteor-bootstrap-Linux_x86_64.tar.gz


Mitar

[Mitar]

Hi!

So, I tested now. It is a forced update. I put the 0.8.3 script here:

http://meteor.peerlibrary.org/

I install 0.8.3 version with curl http://meteor.peerlibrary.org/ | sh
and then I run Meteor and whole .meteor directory is replaced with
0.9.0 version. How do I keep 0.8.3? I cannot. It overrides it
automatically. The .meteor/tools/latest/bin directory is for example
automatically removed and there is no way to prevent that. One just
have to run meteor and it happens.



Mitar

[Mitar]

Hi!

This is very bad for reproducibility. You are saying that you want
build to be always reproducible, but just now all our build are
failing. Because of auto-update.


Mitar

[Daniel Radetsky]

Hopefully, if we keep complaining they'll at least not do it again.

[Mitar]

Hi!

I think they will not do it after moving to 1.0. :-) But they have to
cut some past out of the image to get there.


Mitar

> "meteor-core" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to meteor-core...@googlegroups.com.
> To post to this group, send email to meteo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/meteor-core.

[Ry Walker]

Pretty annoying how some in the community are behaving about this release.

MDG will fix the issues — report your bugs/issues, give them a little breathing room.

They're not trying to ruin your day. Sheesh.

-Ry

[Mitar]

Hi!

Cool. I made installation script which installs 0.8.3 and disables autoupdate:

curl http://meteor.peerlibrary.org/ | sh

So you will stay at 0.8.3 forever. ;-)


Mitar

[David Glasser]

Well, given that the entire point of this release is putting better infrastructure into place so that "meteor update" doesn't touch your app at all unless it has a good reason to believe that your app will be compatible with the update, yes, hopefully we won't put you through another iteration of this :)  Trust me, none of us want to replace the entire "how you install Meteor and its packages" systems again any time soon!  It's way more fun to add useful features to the framework than to rewrite the package downloader.

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.

[Daniel Radetsky]

So long as the message "This went badly" was received, and you'll try* to avoid doing anything like this in the future, I'm satisfied. 

*I can imagine circumstances where there's no way around a forced upgrade; everything will break if you don't upgrade, and only might break if you do. Even so, if this is the case, your little "Hi, we've decided to upgrade your meteor version" message ought to say as much. And you ought to try to avoid running into circumstances where a forced upgrade is the only way out.

[Andrew Mao]

I'm seeing messages of the following sort on IRC:

(10:32:13 PM) ReneAMorales: tried to redeploy my 0.8.3 app to meteor servers and it tried to upgrade me to 0.9.0

(10:32:50 PM) ReneAMorales: I cancelled it and now I can't run my app, it says it's my first time using Meteor and it throws a weird 403 error in curl

Seems like that auto-update message is throwing a lot of people for a loop.

[David Glasser]

Yeah, I'm sorry to hear this was frustrating you today.

I had meant to add a message to the big banner that said "If you cancel this during the installation, don't worry, just run curl install | sh again and you'll be fine, and don't worry, you'll still be able to run your 0.8.3 apps", but it slipped through the cracks.

[Jean Carlos Racoski]

Daniel, I have the same problem... lots read, nothing found yet.
What I do is simply downgrade as they already told you to. But I add: always keep a copy of the smart.lock with the versions of all packages if something gets updated as dependency of something else.
Iron-Router for an example, it is something that in my project... is not going to work with 0.9 so I keep a compliant version locally installed.

There must be a way to disable automatic version upgrades... lots of enterprises rely on the current version to deploy and keep working.

[Avital Oliver]

Auto update does *not* make old apps stop working (since the `.meteor/release` file pins the app to a particular release)! Please someone, explain if this isn't true. Or is there a different concern? (I don't think the format of ~/.meteor changing is what people here are complaining about)

--

You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

PS. I genuinely *really* like receiving feedback of any kind. Leave it anonymously at http://www.admonymous.com/avital

[Avital Oliver]

To clarify: *other than for 0.9.0*, all that auto update does is download the new release and put it in newly created directories in ~/.meteor.

[Pat Moore]

Hi there --

First I appreciate the effort the meteor team is putting into this project. My points are intended in the spirit of making the project better.

While it seems like a benefit at first blush - forced upgrades are always always a bad idea in the enterprise. I am assuming that meteor is intended for enterprise level websites and not just prototyping ideas.

Autoupdate is *always* a problem because:

1. Enterprise builds need to be repeatable. If we are patching a production build that is running meteor 1.0, we need to be able to run a 1.0 build even if the current Meteor is 1.2
   
2. Developers/Enterprises working toward a release schedule do not want to have to "fix" breakage issues that are only caused by the Meteor team proudly releasing a new build.
3. Marketing / CEOs get very upset if a release that they have press events scheduled around fails because that morning Meteor pushes a new release that breaks the deployment.
4. Ops teams get very upset if spinning up a new server causes meteor to autoupgrade resulting in one "bad apple" server out of of 50 servers.
5. Managers get pissed that their recommendation of using Meteor results in them getting a major lecturing/passed over for promotion/and/or termination for missing key milestones because Meteor does forced upgrades.
6. ... more....

I know that many developers regard deadlines as an "optional" suggestion. This is not the case at all, this is especially true in the retail space. Not having your sh*t together and solid before Thanksgiving and Christmas shopping season can kill a retail company's quarter and maybe even the company. Try having a major promotional event with big ad dollars spent : for example Super Bowl ads, and then have Meteor do a forced upgrade on you on Super Bowl sunday. 

Super Bowl does not get rescheduled because a company is having meteor induced deployment issues. Christmas is not moved to December 26. Presidents Day sales events can't be postponed until the next weekend.

One last time: Autoupdates are bad, bad, bad in enterprise software.

This has nothing to do with how big the Meteor team is, nor does it have anything to do with "not showing appreciation" - if Meteor wants to be a framework for toy, prototyping applications then forced updates are fine.

Thank you for your time.

-Pat Moore

[Pat Moore]

Sorry -- one additional point that sometimes gets forgotten:

I do not know a single Ops person that likes the idea of production software going out to a "random" site on the internet to *even* check for an upgrade. Because this is what malware does, quality Ops teams have alarms that go off when this happens. If they are very good they have DNS locked down so that the meteor domain will not resolve for production boxes AND have the alarms go off.

[David Greenspan]

Someone can correct me if I'm wrong, but the best way to run a meteor app in production (aside from "meteor deploy") is probably to "meteor bundle" it first, rather than running the meteor command-line tool in production.

Did we account for the tool being used in production?

-- David

[Andrew Mao]

Well, when you make something too easy to use, people take shortcuts :-\

[Pat Moore]

Correct me if I am wrong but running meteor bundle triggers the forced auto update.

[Abigail Watson]

Hi,
Thanks to the MDG for all their hard work, and the exciting new features in 0.9!  

@Avital...  I think iron-router hasn't been available to developers via Atmosphere for the past 24 hours or so.  The updater is working, but the package ecosystem is suddenly different.   And it's the broken package dependencies that are breaking apps, not the updater.  

I've tried upgrading a few apps now. Here are some case studies from the past 24 hours:

App A uses a dozen packages and auto-updated itself when I ran a regular 'sudo mrt' command, tried to find iron-router, and crashed and burned.  I was able to find old references to iron-router and replace them with iron:router, and get things up and working again.  But for people who have come to Meteor within the past 6 months, it's unlikely that they'd know how to make those kinds of changes.  The auto-update when running a regular 'sudo mrt' command was definitely a bit of a surprise.   

App B uses a dozen packages, including iron-router, and failed to update because six of the packages it relied on hadn't been migrated to the new package management system.  It's was stuck at 0.8.3, and tried to upgrade itself each time I ran it; and failed.  It's unknown when some of those packages are going to get upgraded, so it looked like app B was going to be stuck at 0.8.3.  To make things worse, the iron-router package was apparently removed from Atmosphere, making 0.8.3 broken also.  That was rather worrisome.

App C is the velocity-example app with no dependencies on iron-router. When I ran 'meteor', I got the following error message.  

Error: Package missing from warehouse: standard-app-packages version 9859ad2b1a

For the second app, we're actually looking at temporarily blocking the IP address of the Meteor server from our datacenter, to try to prevent any auto-updating.  

@David...  we use 'meteor bundle' in a deploy script to production, but first we do a 'mrt update' to grab latest package versions.  If we update to 0.9.0 we loose half of our packages that haven't been auto-migrated yet; if we stay on 0.8.3, we don't have access to iron-router since it was upgraded and deprecated.  I just double checked 'meteor bundle', and it does not launch the auto-updater.  


UPDATE:  Okay, after writing all that up, I went and re-ran the updates on old versions of App A and App B, to double check when the auto-updater was running before sending this email out.  Everything is behaving much better now.  It appears that iron-router is available through mrt again on 0.8.3 versions.  I was also getting a 'could not resolve github.com' error which seems to have cleared up.  Everything seems to be updating more consistently and behaving somewhat as expected now.

Did Atmosphere get rebooted in the past 4 hours?  Could traffic as everybody was updating their installations have caused it to backlog and hang?  Could a downed GitHub DNS resolver have caused packages not to have been resolved?  My suspicion is that something along those lines was causing hiccups.  

[David Glasser]

Running 'meteor bundle' does automatically download some new software.  Since the new software uses a new distribution mechanism, it does a clean install of the new software.

It then will immediately re-download the old version you were using and continue using the old version you were using before.  It will not update your app unless you run 'meteor update'.

I hear that people are frustrated that there was an additional surprising step that used a bunch of network and was maybe not as clear as it should be about what it was doing.  I'm sorry that we didn't make the messaging more clear.

But while a bunch of people have said that the situation was confusing and upsetting for them, as far as I know nobody has said that, after the update installed, they were not still able to have perfectly reproducible runs of their Meteor 0.8.3 apps.  If anybody says anything otherwise, fixing that will be our top priority.  But that part of the system seems to work.

To put it another way: if instead of printing a big banner about "hey we're upgrading your Meteor and replacing the distribution", we had just printed "Meteor is doing some work now.  Please be patient and don't hit ctrl-c.", nobody would have noticed anything different except for the fact that there was one surprising random bit of slowness in one execution of Meteor.

We are super in favor of reproducible builds.  That's why we built this system that allows you to have multiple versions of all your packages *AND THE TOOL* installed and makes this actually work!

--dave

[David Glasser]

Abigail, automatically running any update command as part of a deploy script sounds like a bad idea to me.  Surely you should always be testing your updates locally first.

--

You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.

[Abigail Watson]

Oh, we definitely test our updates locally first.  

But if production environment is on 0.8.0, and development environment is on 0.8.3, when we go into our production environment and pull from GitHub, the codebase will then be on 0.8.3 but the environment will still be on 0.8.0.  That's why we've been running 'mrt update'... so as to sync the production environment to the codebase that's been recently pulled.  And we're trying to automate it, so it can auto-clone our VMs.  That's how the 'meteor update' snuck into our deploy script.  

In 20/20 hind sight, it sounds like we need to adjust our deploy scripts to specify a specific --release version, rather than do a 'latest update'.  But if it happened to us, it's possibly/probably happen to others.  

Also, it's sometimes the case that a bundle that's created on a development machine won't run on a production machine, due to architecture issues.  It usually happens when node versions are out of sync.  Which is why one might like to bundle on the production machine that the app is going to run on; which is why one would do a git pull, rather than bundle on a development machine and just scp the bundle to the production server.  Those kinds of issues can definitely affect how deploy scripts get written.  We started off with an scp approach until we had node compatibility versions, which is why we moved to the git pull approach.  

Anyhow.  Notes and feedback from the field.  $0.02

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/wLxgDhtr7HM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.

[Daniel Radetsky]

By the way, David, sorry I called you a crackhead. I was having a very bad day.

[Turbo]

Please note the problem I had with installation below.

We do appreciate product updates, but you must understand that production environment needs to be static and reliable including reboots until we verify all updates/changes are ready to be deployed.

Requirement: Do not update meteor in any way unless 'meteor update' has been run.

Business Reasons:

1) When we deploy to a production environment, it is to be untouched for 3+ months while make changes for the next release.

2) Production environment is operated by non-developers and the deliverable we give them needs to work AS-IS.

3) This framework is B2B, but our customers are also B2B that depends on minute to minute reliability.

   a) We serve to thousands who themselves have tens to hundreds of thousands customers.

4) Our high availability servers are all for nothing if they all get hit with auto-update.

5) Our automation scripts run for 8+ hours. If Meteor changes, we might not know for a long time the impact.

6) We use 33 plugin packages. Something is going to break.

7) We have a custom bundler.js and minifier package to add IE9 CSS 4095 limit support; this gets removed with each upgrade and needs repatching that can't be automated.

8) Update does not always work as expected. Please see my log.

Your automatic update attempted to be too smart. It was to integrate meteorite with meteor even though in the end, it lets you run 0.8.3, the system was down for hours trying to figure this out locally to then fix integration/pre-production server then production.

What should have happened was there should have been an update available for 0.9.0 and let people upgrade on their own schedule. What is confusing is that it says I'm running 0.8.3, but it is really a 0.8.3 revision or wrapper since the the auto-update (or in my case reinstall) piece is completed.

vmlnx-turbo /home/turbo/meteor-dev/cmdctr-app> meteor

*********************************************************************

Exciting news! The Meteor package system has gotten a major upgrade.

The Meteor package system is now fully integrated into Meteor

(you no longer need to install Meteorite) and officially supported by

the Meteor core team.

Your Meteor install will now be updated to the new system. This may

take a few minutes. You may see some unusual or surprising messages

as it happens. That is normal and will only happen this one time.

*********************************************************************

Removing your existing Meteor installation.

rm: cannot remove `/home/turbo/.meteor/tools/8301fde275/bin': Directory not empty

Installation failed.

vmlnx-turbo /home/turbo/meteor-dev/cmdctr-app> meteor

'/home/turbo/.meteor' exists, but '/home/turbo/.meteor/meteor' is not executable.

Remove it and try again.

vmlnx-turbo /home/turbo/.meteor/tools/8301fde275/bin> ls -al

total 8

drwxr-xr-x 2 turbo sw 4096 Aug 27 11:52 ./

drwxr-xr-x 3 turbo sw 4096 Aug 27 11:52 ../

vmlnx-turbo /home/turbo/.meteor/tools/8301fde275> rmdir bin

vmlnx-turbo /home/turbo/.meteor/tools/8301fde275> cd

vmlnx-turbo /home/turbo> sudo curl https://install.meteor.com/ | sh

[sudo] password for turbo: 

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0Removing your existing Meteor installation.

100  4504    0  4504    0     0   3499      0 --:--:--  0:00:01 --:--:--  5400

Downloading Meteor distribution

######################################################################## 100.0%

Meteor 0.9.0 has been installed in your home directory (~/.meteor).

Writing a launcher script to /usr/local/bin/meteor for your convenience.

This may prompt for your password.

To get started fast:

  $ meteor create ~/my_cool_app

  $ cd ~/my_cool_app

  $ meteor

Or see the docs at:

  docs.meteor.com

vmlnx-turbo /home/turbo/meteor-dev/cmdctr-app> meteor

Refreshing package metadata. This may take a moment.

Installing Meteor 0.8.3:

 * 'meteor' build tool (version cef2bcd356)

 * Package updates: accounts-base accounts-facebook accounts-github

   accounts-google accounts-meetup accounts-meteor-developer accounts-oauth

   accounts-password accounts-twitter accounts-ui accounts-ui-unstyled

   accounts-weibo amplify appcache application-configuration

   audit-argument-checks autopublish autoupdate backbone binary-heap blaze

   blaze-tools bootstrap browser-policy browser-policy-common

   browser-policy-content browser-policy-framing callback-hook check

   code-prettify coffeescript coffeescript-test-helper ctl ctl-helper d3 deps

   dev-bundle-fetcher disable-oplog ejson email facebook facts follower-livedata

   force-ssl geojson-utils github google handlebars html-tools htmljs http

   id-map insecure jquery jquery-history jquery-layout jquery-waypoints

   js-analyze js-analyze-tests json jsparse less livedata localstorage logging

   meetup meteor meteor-developer meyerweb-reset minifiers minimongo

   mongo-livedata oauth oauth-encryption oauth1 oauth2 observe-sequence

   ordered-dict preserve-inputs random reactive-dict reload reload-safetybelt

   retry routepolicy service-configuration session sha showdown spacebars

   spacebars-compiler spacebars-tests spiderable srp standard-app-packages

   star-translate startup stylus templating test-helpers test-in-browser

   test-in-console tinytest twitter ui underscore underscore-tests webapp weibo

[[[[[ ~/meteor-dev/cmdctr-app ]]]]]

=> Started proxy.

                        

=> Meteor 0.9.0: Introducing the official Meteor package system,

   including Isobuild and the Meteor Package Server!

   Starting in 0.9.0, you can publish your own packages and use any of

   the over 1800 community packages in your app, without needing an

   external tool such as Meteorite. Just use commands like 'meteor add

   <packagename>', 'meteor publish', and 'meteor search <query>'.

   This release is being downloaded in the background. It's a big

   change! Once it's done downloading, then the next time you run

   'meteor', your Meteor install will be automatically upgraded to the

   new system. The upgrade will take a few minutes and as part of it

   old versions of Meteor will be removed from your machine. These old

   versions will be automatically redownloaded using the new system if

   you work on apps that use them.

=> Started MongoDB.     

=> Meteor 0.9.0 is available. Update this project with 'meteor update'.

[Tom Coleman]

I would just briefly say that `mrt update` seems like the wrong thing to do in this case. 

It’s probably academic now, given 0.9.0, but if you are checking `smart.lock` into your git repo, then you just need to run `mrt install` (or any `mrt` command really) to get the exact same versions of all packages that you have tested with in development. 

`mrt update` would risk getting a brand new version of some package that was literally just released. There’s no way you want to do that.

Note as well that `mrt update` doesn’t run `meteor update`. So that’s a whole different story.

[David Glasser]

"meteor" is a local development tool.  You should not be using the meteor command to run your app in production.

--

[David Glasser]

I appreciate that.

--

[Patrick Scott]

First off, I'm looking forward to getting the new version of meteor running. MDG has done amazing work in the past and I'm excited about the benefits of the new package manager.

Trying to work on a train.. got hit by the auto-update failing due to very spotty network connection and just kept getting messages that said "This is the first time running meteor..." and a 403 error. Very confusing error messages here.

Because ALL of my apps stopped working, I was able to assume the the meteor installation was removed and failed to download the new version.. I think this thread says the messages needs to be better, but also maybe check that a user is able to successfully able to download the new version before deleting the old one, as now I can't get any work done over the next couple hours on the train because I can't keep an internet connection long enough to reinstall meteor again.

[Dave Workman]

I just want to add my own few words to this. Great work to all the guys and gals at MDG. I think it was around 0.3-0.4 (last April) when I started using Meteor and it's come a long way (although, were not at 1.0 even though it's way past 1st quarter of 2014 *wink* *wink*, kidding!).

I really must be missing something here. The 0.8 (Blaze) update was WAY worse than this. I was prepared for a least few days work to get everything working on 0.9.0 and I can say I deployed this morning running 0.9.0 and apart from typing meteor update, running my test suites in all the major browsers the only thing I had to do was change my deploy script that unpacks the bundle from uninstalling and reinstalling fibers and bcrypt to uninstalling those and running npm install inside programs/server/app/server (had some complains about underscore and a few other modules not being found). I'm really impressed, and quite happy because I was getting lots of complains from people running iPads and macbooks having my app crash on them.

I think we all know what we signed up for developing with pre-release software. The amount of time Meteor saves more than makes up for the occasional headache.

[Mitar]

Hi!

On Wed, Aug 27, 2014 at 9:41 AM, David Greenspan <da...@meteor.com> wrote:
> Someone can correct me if I'm wrong, but the best way to run a meteor app in
> production (aside from "meteor deploy") is probably to "meteor bundle" it
> first, rather than running the meteor command-line tool in production.
>
> Did we account for the tool being used in production?

We are using Docker images in production. It uses meteor bundle
internally. But to get to meteor bundle, you have to run meteor.
Running meteor ... oooh, it is getting upgraded, and build fails,
because assumptions on how it will behave changed between versions.

So how I can make a build system, which installs exactly the known
version of Meteor as part of the system, without it getting updated
automatically, which breaks assumptions about what is getting
installed? So reproducibility and stuff?


Mitar

> "meteor-core" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to meteor-core...@googlegroups.com.
> To post to this group, send email to meteo...@googlegroups.com.
>
> Visit this group at http://groups.google.com/group/meteor-core.

> For more options, visit https://groups.google.com/d/optout.

[Mitar]

Hi!

On Wed, Aug 27, 2014 at 11:10 AM, Abigail Watson <awats...@gmail.com> wrote:

> For the second app, we're actually looking at temporarily blocking the IP
> address of the Meteor server from our datacenter, to try to prevent any
> auto-updating.

We just started using everywhere:

export METEOR_TEST_UPDATE_MANIFEST="offline"

Which stops autoupdate.


Mitar

[Mitar]

Hi!

On Wed, Aug 27, 2014 at 12:09 PM, David Glasser <gla...@meteor.com> wrote:
> But while a bunch of people have said that the situation was confusing and
> upsetting for them, as far as I know nobody has said that, after the update
> installed, they were not still able to have perfectly reproducible runs of
> their Meteor 0.8.3 apps. If anybody says anything otherwise, fixing that
> will be our top priority. But that part of the system seems to work.

This is not true. I opened a ticket and expected top priority, and you
just closed it and didn't do anything:

https://github.com/meteor/meteor/issues/2445

You can say that the problem is because we are using Meteor internals,
but this exactly is the reason why one does not want to use
autoupdate, so that we can test our assumptions about internals when
there is a new version. You made autoupdate and broke things without a
way for us to say "no, please don't autoupdate, because we have to
check if assumptions still hold".

But the consequence is good. We learned that we cannot trust
install.meteor.com, because it breaks things without warning, so we
are now hosting our own version, which we can control and not be
surprised anymore. So probably this is the way how you really get
reproducibility, you have to host things yourself.

> To put it another way: if instead of printing a big banner about "hey we're
> upgrading your Meteor and replacing the distribution", we had just printed
> "Meteor is doing some work now. Please be patient and don't hit ctrl-c.",
> nobody would have noticed anything different except for the fact that there
> was one surprising random bit of slowness in one execution of Meteor.

Not true. It would still break our production build system. It would
still not ask for permission to update at all.

> We are super in favor of reproducible builds. That's why we built this
> system that allows you to have multiple versions of all your packages *AND
> THE TOOL* installed and makes this actually work!

Great. And why cannot we choose the previous versions then? Why script
from a week ago does not work anymore? It was running very well with
automatic builds on docker.io, but then it broke. This is not really
reproducibly.


Mitar

> On Wed, Aug 27, 2014 at 10:09 AM, Pat Moore <transpare...@gmail.com>
> wrote:
>>
>> Correct me if I am wrong but running meteor bundle triggers the forced
>> auto update.
>>
>>
>> On Wednesday, August 27, 2014 9:57:40 AM UTC-7, Andrew Mao wrote:
>>>
>>> Well, when you make something too easy to use, people take shortcuts :-\
>>>
>>> On Wednesday, August 27, 2014 12:41:50 PM UTC-4, David Greenspan wrote:
>>>>
>>>> Someone can correct me if I'm wrong, but the best way to run a meteor
>>>> app in production (aside from "meteor deploy") is probably to "meteor
>>>> bundle" it first, rather than running the meteor command-line tool in
>>>> production.
>>>>
>>>> Did we account for the tool being used in production?
>>>>
>>>> -- David
>>>>
>>>>
>>>>
>>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "meteor-talk" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to meteor-talk...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups

> "meteor-core" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to meteor-core...@googlegroups.com.
> To post to this group, send email to meteo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/meteor-core.

> For more options, visit https://groups.google.com/d/optout.

[Mitar]

Hi!

On Wed, Aug 27, 2014 at 1:28 PM, Abigail Watson <awats...@gmail.com> wrote:
> But if production environment is on 0.8.0, and development environment is on
> 0.8.3, when we go into our production environment and pull from GitHub, the
> codebase will then be on 0.8.3 but the environment will still be on 0.8.0.
> That's why we've been running 'mrt update'... so as to sync the production
> environment to the codebase that's been recently pulled. And we're trying
> to automate it, so it can auto-clone our VMs. That's how the 'meteor
> update' snuck into our deploy script.

Hm. I think what you wanted there is "mrt install", not "mrt update".
"mrt install" would sync your installation with things from
smart.lock, while "mrt update" goes and updates from the latest from
Atmosphere. Which you probably don't want in production builds?


Mitar

http://mitar.tnode.com/
https://twitter.com/mitar_m

[ega radiegtya]

THANKS METEOR!#$%^

Yesterday night was our company presentation day at our BIGGEST CLIENT office.

Yesterday morning suddenly I got message that meteor has been updated to v 0.9.0. 

Ok, then I'll try not to update it until our night presentation.
BUT WHEN I DEPLOY MY APPS USING MRT FOR TESTING SUDDENLY METEOR SAID AUTO UPDATED TO V.0.9.0! WTF THEN I FORCE PRESS CTRL+C.

Then our apps cannot be run, that's really our bad day before presentation. 

I have no idea how to make things clear. So I remove .meteor installation and reinstall it. Fortunately it's work, and we can did presentation at night with some of meteorite plugin not working perfectly :))

Ok maybe if it was a TOY apps we can re-code it easily. But what we make here are ENTERPRISE APPS WHICH IS AN ERP APPS.

I have experienced this thing not only once while using meteor since version 0.7. BUT THIS IS THE WORST.

I don't think this IDEA are good for ENTERPRISE. AND I HOPE METEOR TEAM DOES'T MAKE METEOR A TOY FRAMEWORK.

ONCE AGAIN, THANKS METEOR FOR THE BEST DAY U GAVE!@#$%^&*()

[Pat Moore]

Sorry to hear this happened. Blocking install.meteor.com does seem like the best approach and one that I am following on my box.

We had about a 2 hour scramble on our end, before an important internal milestone where we were presenting to the CEO. At least for us we had a day to recover - but it did nothing for my stress level.

-Pat

[Don MacKinnon]

Meteor Team

Please don't force auto upgrades. There are a lot of packages that aren't updated and the auto update process screwed up the install of meteor on my system because I didn't start my app using sudo (didn't know it was going to autoupdate).

[Andrew Mao]

Please don't use sudo to run Meteor. I really don't understand it, I just saw another guy doing that here: https://github.com/TimHeckel/meteor-bootboxjs/issues/14

It's true though that MDG violated the principle of least surprise with that auto-update-that-wasn't-really-an-auto-update. Many users pressed Ctrl-C when they saw that message, breaking their install and needing some more legwork to fix it again.

[Don MacKinnon]

I don't use sudo, that's the problem. The meteor auto update didn't run correctly because it lacked the permissions to update the global install. It's a shared environment.

--

You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/wLxgDhtr7HM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Don MacKinnon
Lead Developer, Revolution Labs
dmac...@revolutionlabs.com

[Andrew Mao]

If you think you are having a bad day, you should check out the day I had when I tried to run my (pseudo-production) app on 0.9.0-rc5.

It's all documented in this group :)

[Abigail Watson]

:fingerscrossed: that integrating mrt and meteor reduces the need to run things as sudo.  There's been a need for an audit script for checking Meteor permissions for a long time, but I have yet to see somebody attempt one.  

[matt debergalis]

My apologies to anyone adversely affected by the 0.9.0 update. We
didn't deliver what you've come to expect from us. We'll learn from
it and get better.

Two points here. First, our messaging wasn't up to the Meteor
standard. "Your Meteor install will now be updated to the new system"
didn't make it clear that only the tool is getting updated and that an
*application* built against an early release will still run unchanged
after the update. If I'd been working on a production app, seeing
that would have sent me straight to C-c too. Second, we made the
decision to simplify the transition to the new packaging system by
pushing the new 0.9.0 tool to everyone and not trying to support the
new and old system in parallel. Glasser made the case for doing this
earlier in the thread, but there's a strong counter argument that Pat
and others have raised, and it wasn't much (at all?) discussed on the
core list beforehand.

Why did these things happen? The thinking goes like this: since 1.0
means a stable set of core APIs that we can stand behind for long-term
production use, the best thing we can do for the project is *get to
1.0 quickly*! So we've generally been willing to make breaking
changes and encourage everyone to take frequent updates. On top of
that, the update of the package infrastructure was a particularly
gnarly one, kind of like changing out a house's foundation while
there's a dinner party going on upstairs. We knew an update like this
would only have to happen once before 1.0 and we thought it was at a
point where it'd be vastly better for most Meteor developers and
package authors. So we decided to get it out there without the level
of investment that we'd have needed to support a *completely* seamless
transition, instead putting that effort into other parts of 1.0.

In this case, I think we missed the right balance. The good news is
this update was a one-time thing: MDG and third party package
developers can now deliver the balance of what's coming before 1.0 --
changes that you'll be able to take at the time of your choosing --
without this kind of disruption, in large part due to the architecture
of Isobuild and the new package system.

Let me also be crystal clear. We have specifically designed Meteor,
the Meteor release process, the new Meteor package system, Isobuild,
and (further down the line) Galaxy to meet the needs of enterprise
environments that need stable and repeatable builds and deployments.
Pat's email hits all the right points. The pieces we've been putting
in place -- like the concept of a Meteor release (such as 0.9.0.1 or
1.0.2) that package developers can target -- are designed to make
building isomorphic apps in JavaScript a frustration-free experience
where application developers don't have to grind through nearly so
many releng details. I remember the nightmarish update process in the
early days of Linux before RedHat and RPM came along and I think about
how routine it is now to keep an Ubuntu stack up to date w/ security
patches. I'm excited about a future like this for JavaScript and hope
you are too!

>> On Tue, Aug 26, 2014 at 6:38 PM, Daniel Radetsky <drad...@gmail.com>
>> wrote:
>>>
>>> So long as the message "This went badly" was received, and you'll try* to
>>> avoid doing anything like this in the future, I'm satisfied.
>>>
>>> *I can imagine circumstances where there's no way around a forced
>>> upgrade; everything will break if you don't upgrade, and only might break if
>>> you do. Even so, if this is the case, your little "Hi, we've decided to
>>> upgrade your meteor version" message ought to say as much. And you ought to
>>> try to avoid running into circumstances where a forced upgrade is the only
>>> way out.
>>>
>>> On Tuesday, August 26, 2014 6:12:58 PM UTC-7, David Glasser wrote:
>>>>
>>>> Well, given that the entire point of this release is putting better
>>>> infrastructure into place so that "meteor update" doesn't touch your app at
>>>> all unless it has a good reason to believe that your app will be compatible
>>>> with the update, yes, hopefully we won't put you through another iteration
>>>> of this :) Trust me, none of us want to replace the entire "how you install
>>>> Meteor and its packages" systems again any time soon! It's way more fun to
>>>> add useful features to the framework than to rewrite the package downloader.
>>>>
>>>>
>>>> On Tue, Aug 26, 2014 at 5:27 PM, Daniel Radetsky <drad...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hopefully, if we keep complaining they'll at least not do it again.
>>>>>
>>>>>
>>>>> On Tuesday, August 26, 2014 5:11:57 PM UTC-7, Mi Tar wrote:
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> This is very bad for reproducibility. You are saying that you want
>>>>>> build to be always reproducible, but just now all our build are
>>>>>> failing. Because of auto-update.
>>>>>>
>>>>>>
>>>>>> Mitar
>>>>>>
>>>>>> On Tue, Aug 26, 2014 at 5:09 PM, Mitar <mmi...@gmail.com> wrote:
>>>>>> > Hi!
>>>>>> >
>>>>>> > So, I tested now. It is a forced update. I put the 0.8.3 script
>>>>>> > here:
>>>>>> >
>>>>>> > http://meteor.peerlibrary.org/
>>>>>> >
>>>>>> > I install 0.8.3 version with curl http://meteor.peerlibrary.org/ |
>>>>>> > sh
>>>>>> > and then I run Meteor and whole .meteor directory is replaced with
>>>>>> > 0.9.0 version. How do I keep 0.8.3? I cannot. It overrides it
>>>>>> > automatically. The .meteor/tools/latest/bin directory is for example
>>>>>> > automatically removed and there is no way to prevent that. One just
>>>>>> > have to run meteor and it happens.
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > Mitar
>>>>>> >
>>>>>> > On Tue, Aug 26, 2014 at 3:02 PM, David Greenspan <da...@meteor.com>
>>>>>> > wrote:
>>>>>> >> To be clear, the new release is not a "forced update" -- it does
>>>>>> >> not force
>>>>>> >> you to update your apps to 0.9.0. You can still run your 0.8.3
>>>>>> >> apps and
>>>>>> >> packages without upgrading them to work with 0.9.0.
>>>>>> >>
>>>>>> >> -- David
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Tue, Aug 26, 2014 at 2:44 PM, Mitar <mmi...@gmail.com> wrote:
>>>>>> >>>
>>>>>> >>> Hi!
>>>>>> >>>
>>>>>> >>> Could you provide a install-0.8.meteor.com script which installs
>>>>>> >>> Meteor 0.8.3 and it keeps it that way?
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> Mitar
>>>>>> >>>
>>>>>> >>> On Tue, Aug 26, 2014 at 2:40 PM, David Greenspan
>>>>>> >>> <da...@meteor.com> wrote:
>>>>>> >>> > I think Andrew and David Glasser are implying that Meteor
>>>>>> >>> > doesn't
>>>>>> >>> > actually
>>>>>> >>> > force-update you to 0.9.0. If so, maybe this is just a
>>>>>> >>> > misunderstanding.
>>>>>> >>> >
>>>>>> >>> > -- David
>>>>>> >>> >
>>>>>> >>> >
>>>>>> >>> >
>>>>>> >>> > On Tue, Aug 26, 2014 at 2:34 PM, Daniel Radetsky
>>>>>> >>> > <drad...@gmail.com>
>>>>>> >>> > wrote:
>>>>>> >>> >>
>>>>>> >>> >> In any case, you've fucked up our release schedule.
>>>>>> >>> >>
>>>>>> >>> >> On Tuesday, August 26, 2014 2:28:58 PM UTC-7, Daniel Radetsky
>>>>>> >>> >> wrote:
>>>>>> >>> >>>
>>>>>> >>> >>> I don't understand why it isn't simpler to not automatically
>>>>>> >>> >>> upgrade
>>>>>> >>> >>> than
>>>>>> >>> >>> to automatically upgrade.
>>>>>> >>> >>>
>>>>>> >>> >>> On Tuesday, August 26, 2014 2:19:04 PM UTC-7, David Glasser
>>>>>> >>> >>> wrote:
>>>>>> >>> >>>>
>>>>>> >>> >>>> We're a small team moving rapidly towards 1.0. In order to
>>>>>> >>> >>>> make
>>>>>> >>> >>>> issues
>>>>>> >>> >>>> feasible to debug, we want to keep complexity down.
>>>>>> >>> >>>>
>>>>>> >>> >>>> It's already complex enough to maintain the system that we
>>>>>> >>> >>>> did
>>>>>> >>> >>>> release,
>>>>>> >>> >>>> where we maintain full backwards compatibility for users
>>>>>> >>> >>>> running
>>>>>> >>> >>>> 0.8.3 and
>>>>>> >>> >>>> older apps after 0.9.0 is installed. Making a system where
>>>>>> >>> >>>> the
>>>>>> >>> >>>> top-level
>>>>>> >>> >>>> runner script could be one of two different platforms would
>>>>>> >>> >>>> be a lot
>>>>>> >>> >>>> more
>>>>>> >>> >>>> complicated and will lead to more bugs.
>>>>>> >>> >>>>
>>>>>> >>> >>>> If you're encountering issues where, after 0.9.0 is installed
>>>>>> >>> >>>> and
>>>>>> >>> >>>> your
>>>>>> >>> >>>> older release is re-downloaded, there is any difficulty
>>>>>> >>> >>>> continuing to
>>>>>> >>> >>>> use
>>>>>> >>> >>>> 0.8.3, please file a bug. We put a lot of time and energy
>>>>>> >>> >>>> into
>>>>>> >>> >>>> enabling
>>>>>> >>> >>>> exactly this use case when we could have just said "You're
>>>>>> >>> >>>> using
>>>>>> >>> >>>> pre-1.0
>>>>>> >>> >>>> software, you have to port your apps to 0.9.0 immediately".
>>>>>> >>> >>>> All our
>>>>>> >>> >>>> tests
>>>>>> >>> >>>> so far show that this mode works, so please report any bugs
>>>>>> >>> >>>> in it.
>>>>>> >>> >>>>
>>>>>> >>> >>>>
>>>>>> >>> >>>>
>>>>>> >>> >>>> On Tue, Aug 26, 2014 at 2:00 PM, Daniel Radetsky
>>>>>> >>> >>>> <drad...@gmail.com>
>>>>>> >>> >>>> wrote:
>>>>>> >>> >>>>>
>>>>>> >>> >>>>> I understand, but you should still take out the auto-upgrade
>>>>>> >>> >>>>> ASAFP
>>>>>> >>> >>>>>
>>>>>> >>> >>>>>
>>>>>> >>> >>>>> On Tuesday, August 26, 2014 1:55:11 PM UTC-7, Andrew Mao
>>>>>> >>> >>>>> wrote:
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> Your project should still be runnable on Meteor 0.8.3.
>>>>>> >>> >>>>>> Don't run it
>>>>>> >>> >>>>>> on
>>>>>> >>> >>>>>> 0.9.
>>>>>> >>> >>>>>>
>>>>>> >>> >>>>>> On Tuesday, August 26, 2014 4:46:58 PM UTC-4, Daniel
>>>>>> >>> >>>>>> Radetsky
>>>>>> >>> >>>>>> wrote:
>>>>>> >>> >>>>>>>
>>>>>> >>> >>>>>>> Our project is too. We used packages with capital letters
>>>>>> >>> >>>>>>> in them,
>>>>>> >>> >>>>>>> which apparently doesn't work anymore. SlickGrid,
>>>>>> >>> >>>>>>> Crossfilter,
>>>>>> >>> >>>>>>> etc. Also,
>>>>>> >>> >>>>>>> airbrake.io isn't working for some reason.
>>>>>> >>> >>>>>>>
>>>>>> >>> >>>>>>> NEVER DO THIS SHIT AGAIN.
>>>>>> >>> >>>>>>>
>>>>>> >>> >>>>>>> Seriously, what were you thinking? Just because it's easy
>>>>>> >>> >>>>>>> to buy
>>>>>> >>> >>>>>>> crack near the Meteor office doesn't mean you have to
>>>>>> >>> >>>>>>> smoke any.
>>>>>> >>> >>>>>>> Just say
>>>>>> >>> >>>>>>> no.
>>>>>> >>> >>>>>>>
>>>>>> >>> >>>>>>> On Tuesday, August 26, 2014 1:31:31 PM UTC-7, Bernardo
>>>>>> >>> >>>>>>> Kuri wrote:
>>>>>> >>> >>>>>>>>
>>>>>> >>> >>>>>>>> No kidding... My current project is completely borked
>>>>>> >>> >>>>>>>> after this
>>>>>> >>> >>>>>>>> auto installation process. At least 4 of the addons I'm
>>>>>> >>> >>>>>>>> using are
>>>>>> >>> >>>>>>>> incompatible with 0.9 and now I'm posting github issues
>>>>>> >>> >>>>>>>> all over
>>>>>> >>> >>>>>>>> the place.
>>>>>> >>> >>>>>>>> Auto updates are always a bad idea.
>>>>>> >>> >>>>>>>>
>>>>>> >>> >>>>>>>> On Tuesday, August 26, 2014 3:17:09 PM UTC-5, Daniel
>>>>>> >>> >>>>>>>> Radetsky
>>>>>> >>> >>>>>>>> wrote:
>>>>>> >>> >>>>>>>>>
>>>>>> >>> >>>>>>>>> So not to infuriate us? Because he's pulled that one off
>>>>>> >>> >>>>>>>>> nicely.
>>>>>> >>> >>>>>>>>>
>>>>>> >>> >>>>>>>>> On Tuesday, August 26, 2014 10:31:15 AM UTC-7, Andrew
>>>>>> >>> >>>>>>>>> Mao wrote:
>>>>>> >>> >>>>>>>>>>
>>>>>> >>> >>>>>>>>>> It'll put the old versions back after removing them.
>>>>>> >>> >>>>>>>>>> Glasser
>>>>>> >>> >>>>>>>>>> just
>>>>>> >>> >>>>>>>>>> put that in to scare us.

>>>>>> >>> >>>>>>>>>>
>>>>>> >>> >>>>>>>>>> On Tuesday, August 26, 2014 1:05:15 PM UTC-4, Daniel
>>>>>> >>> >>>>>>>>>> Radetsky
>>>>>> >>> >>>>>>>>>> wrote:
>>>>>> >>> >>>>>>>>>>>
>>>>>> >>> >>>>>>>>>>> started my proj, and meteor says it is auto-updating
>>>>>> >>> >>>>>>>>>>> me to
>>>>>> >>> >>>>>>>>>>> 0.9.0
>>>>>> >>> >>>>>>>>>>> and removing old versions. I'm trying to do a release
>>>>>> >>> >>>>>>>>>>> this
>>>>>> >>> >>>>>>>>>>> morning and can't
>>>>>> >>> >>>>>>>>>>> deal with upgrading bullshit today. Is there a way to
>>>>>> >>> >>>>>>>>>>> prevent
>>>>>> >>> >>>>>>>>>>> upgrading and
>>>>>> >>> >>>>>>>>>>> stick with 0.8.3 for the time being? Please advise.
>>>>>> >>> >>>>>

>>>>>> >>> >>>>> --
>>>>>> >>> >>>>> You received this message because you are subscribed to the
>>>>>> >>> >>>>> Google
>>>>>> >>> >>>>> Groups "meteor-talk" group.

>>>>>> >>> >>>>> To unsubscribe from this group and stop receiving emails
>>>>>> >>> >>>>> from it,

>>>>>> >>> >>>>> send
>>>>>> >>> >>>>> an email to meteor-talk...@googlegroups.com.
>>>>>> >>> >>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>> >>> >>>>
>>>>>> >>> >>>>

>>>>>> >>> >> --
>>>>>> >>> >> You received this message because you are subscribed to the
>>>>>> >>> >> Google
>>>>>> >>> >> Groups
>>>>>> >>> >> "meteor-talk" group.

>>>>>> >>> >> To unsubscribe from this group and stop receiving emails from

>>>>>> >>> >> it, send

>>>>>> >>> >> an
>>>>>> >>> >> email to meteor-talk...@googlegroups.com.
>>>>>> >>> >> For more options, visit https://groups.google.com/d/optout.
>>>>>> >>> >
>>>>>> >>> >

>>>>>> >>> > --
>>>>>> >>> > You received this message because you are subscribed to the
>>>>>> >>> > Google
>>>>>> >>> > Groups
>>>>>> >>> > "meteor-talk" group.

>>>>>> >>> > To unsubscribe from this group and stop receiving emails from

>>>>>> >>> > it, send

>>>>>> >>> > an
>>>>>> >>> > email to meteor-talk...@googlegroups.com.
>>>>>> >>> > For more options, visit https://groups.google.com/d/optout.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>

>>>>>> >>> --
>>>>>> >>> http://mitar.tnode.com/
>>>>>> >>> https://twitter.com/mitar_m
>>>>>> >>>

>>>>>> >>> --
>>>>>> >>> You received this message because you are subscribed to the Google
>>>>>> >>> Groups
>>>>>> >>> "meteor-talk" group.

>>>>>> >>> To unsubscribe from this group and stop receiving emails from it,

>>>>>> >>> send an
>>>>>> >>> email to meteor-talk...@googlegroups.com.
>>>>>> >>> For more options, visit https://groups.google.com/d/optout.
>>>>>> >>
>>>>>> >>

>>>>>> >> --
>>>>>> >> You received this message because you are subscribed to the Google
>>>>>> >> Groups
>>>>>> >> "meteor-talk" group.

>>>>>> >> To unsubscribe from this group and stop receiving emails from it,

>>>>>> >> send an
>>>>>> >> email to meteor-talk...@googlegroups.com.
>>>>>> >> For more options, visit https://groups.google.com/d/optout.
>>>>>> >
>>>>>> >
>>>>>> >

>>>>>> > --
>>>>>> > http://mitar.tnode.com/
>>>>>> > https://twitter.com/mitar_m
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://mitar.tnode.com/
>>>>>> https://twitter.com/mitar_m
>>>>>

>>>>> --

>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "meteor-core" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to meteor-core...@googlegroups.com.
>>>>> To post to this group, send email to meteo...@googlegroups.com.
>>>>>
>>>>> Visit this group at http://groups.google.com/group/meteor-core.
>>>>>

>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>

>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "meteor-talk" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an

>>> email to meteor-talk...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>

> --
> You received this message because you are subscribed to the Google Groups
> "meteor-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an