What happened to beta.13, beta.14, and beta.15? All unfortunately suffered
from problems that made it either impossible or unwise to upgrade to those
versions.
Tried to get everything to an rc.0 of the very latest version,
which required some research in some cases about the published
versions. For example, some packages had version histories like:
```
...
1.0.3-winr.2 January 20th, 2015
1.0.3-winr.3 February 24th, 2015 installed
1.0.3 March 17th, 2015 installed
1.0.4-anubhav.0 August 6th, 2015
1.0.4-plugins.0 July 22nd, 2015
1.0.5-galaxy.0 July 17th, 2015
```
In this case, I would bump the version from `1.0.4-plugins.0`
to `1.0.5-rc.0`, skipping `1.0.4`.
Discussion/plan here: https://github.com/meteor/meteor/pull/4851
`meteor-platform will no longer be a part of future Meteor releases. Apps
`upgraded to Meteor 1.2 will be automatically updated to use the packages listed
`above instead of meteor-platform. (Along with a set of packages like EJSON and
`Random that used to be in meteor platform but probably shouldn’t have been)
After this project, here is the set of packages that will be included by default
in a newly created Meteor app:
1. `meteor-base` is the set of packages that basically every single Meteor app will have. If you don’t have these packages, you are probably doing something that isn’t really supported, like building a command line tool or switching out the whole web server stack. It comes with the following packages:
1. `meteor` - this includes stuff like `Meteor.isClient`, a default handler for `css` files, etc.
2. `webapp` - this is responsible for handling actual HTTP connections, Websockets, and serving files
3. `underscore` - almost all of Meteor is built on top of underscore, so it makes sense to let people assume that most or all Meteor apps right now will have this included
4. `autoupdate` - refreshing the client is a core part of the Meteor development experience, and it’s integrated into several layers of the stack
5. `ddp` - lots of core parts of Meteor assume that DDP can be used to communicate between client and server
2. `standard-minifiers` minifies your JS and CSS code in production
3. `ecmascript` allows you to write your app using new ES2015 JavaScript features
4. `es5-shim` polyfills some newer APIs in old and non-compliant browsers, in particular IE8
5. `mobile-experience` is a set of cordova-specific packages that set some good defaults when building for mobile. These packages only activate when you are building a native Android or iOS app.
1. `fastclick` - avoid the 300ms touch delay
2. `mobile-status-bar` - avoid the status bar information covering up your app content
3. `launch-screen` - cover the app with a launch image so that people don’t have to see things loading
6. `mongo` is the package that enables Meteor to connect to MongoDB on the server and watch queries in real-time. It also includes Minimongo for the client so that you can publish Mongo documents over DDP. This package will be removable in case you want to use one of the community-supported drivers for alternate databases, and for the desirable future where Meteor supports other databases officially.
7. `blaze-html-templates` compiles your `html` files with Spacebars and includes the Blaze runtime on the client so that the templates can run. If you remove this, you might want to include a different view layer like `react`, or `angular`, and use a package for rendering the starter HTML like `static-html` (also coming out in Meteor 1.2)
8. `tracker` the package that powers a lot of Meteor’s reactive APIs on the client. Including it in the app allows you to use `Tracker.autorun` directly.
9. `session` a simple global reactive dictionary for the client.
10. `jquery` a convenient utility library for the client.
11. `insecure` a prototyping package that lets you make any database modifications from the client.
12. `autopublish` a prototyping package that lets you access the whole database (except sensitive user data) from the client.
This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
