Meteor 0.9.3 is out today.

The highlights in this release are of primary interest to package authors. More on that below, and in the release notes.

There are also some improvements in 0.9.3 for everyone (that’s you!) using the new package system. Running meteor update will upgrade to pre-release versions of packages (those that include a - in their version string) when necessary; many package operations run faster; we added progress bars to the time-intensive operations; and new diagnostic messages make it much easier to sort out package dependency issues during an update.

There are no breaking changes in 0.9.3.

We’re getting close now to Meteor 1.0. The more developers we have running the most recent Meteor releases, the shorter we’ll be able to make the final train of 1.0 release candidates. So please give it a try and let us know how it works for you!

For package authors, here’s a summary of the new features. Again, please consult the release notes and full Meteor docs for more info.

Packages can now depend on any of several releases of the Meteor distribution or on multiple major versions of a particular package. This change makes it easier to maintain packages that work across a range of Meteor versions: you no longer have to maintain separate forks and publish multiple versions of your package to support multiple versions of Meteor.

To do this, pass an array of specification strings to api.versionsFrom or just call api.versionsFrom multiple times in the package.js control file, or use the new || operator when calling api.use to specify multiple version constraints for an individual package dependency (eg: api.use('blaze@1.0.0 || 2.0.0') for any 1.x.x or 2.x.x version of Blaze, or api.use('blaze@1.0.0 || =2.0.1') to mean 1.x.x plus specifically version 2.0.1.).

or just call multiple times in the control file, or use the new operator when calling to specify multiple version constraints for an individual package dependency (eg: for any 1.x.x or 2.x.x version of Blaze, or to mean 1.x.x plus specifically version 2.0.1.). We’ve added support for “wrapped package” version numbers by adding a fourth version component separated by _ . This addition makes it possible to base package versions on an upstream semver while still permitting you to publish multiple versions of your package that are based on the same upstream version. The component following the _ must be an integer and wrapped version numbers sort as you'd expect. (For example, if you've wrapped Bootstrap as a package, you might publish a series of updates based on Bootstrap 3.2.0 as yourname:bootstrap@3.2.0 , yourname:bootstrap@3.2.0_1 , and yourname:bootstrap@3.2.0_2 .)

. This addition makes it possible to base package versions on an upstream semver while still permitting you to publish multiple versions of your package that are based on the same upstream version. The component following the must be an integer and wrapped version numbers sort as you'd expect. (For example, if you've wrapped Bootstrap as a package, you might publish a series of updates based on Bootstrap 3.2.0 as , , and .) A new administrative command hides packages from the results of meteor search and meteor show . This is designed to remove mrt-era packages that didn't correctly auto-migrate into the new package system and for cases where authors have changed the name of a package and don't want new developers using the old name. To hide a package, run meteor admin set-unmigrated . Please note that hiding a package does not prevent users from explicitly adding it.

And as always, thanks to our Github contributors who made contributions to the release: evliu, meonkeys, mitar, mizzao, mquandalle, prapicault, waitingkuo, wulfmeister.