We were accidentally considering this equivalent to 'meteor update
--release LATEST', meaning we could not update to an intermediate
release (and that it could update you backwards).
Many of these (mostly in top level commands in commands-packages.js) are
not super well thought out: they use a new "doOrDie" helper to run some
function in a capture and exit if there are any messages. We really
need to get a little more thoughtful about the big picture of error
handling (combining "build" errors, network errors, catalog errors,
etc). But this at least allows the addition of more buildmessage
assertions.
At the very least, this ensures that if you edit a package.js in a local
package while "meteor run" is running, that instead of crashing the tool
it properly shows the buildmessage and lets you fix the issue.
Specifically, in cases (like "load the most recent release we know
about") where we don't always want to incur a sync RPC.
Apparently, there is literally no way to get data from catalog.official
without a sync RPC occuring.
This speeds up 'meteor --version' on built releases by a factor of 10
also fixes a bunch of other stuff like:
- parseStack markTop works again (so you get the right line numbers in
self-test)
- you can (with appropriate env var) run apps with NO PACKAGES at
all (even ctl)
- more consistently refer to METEOR-CORE@ releases as "Meteor 1.2.3"
other changes:
- defaultReleaseVersion is not synced using 'collections' any more,
since it is a singleton and has different merge logic
- publish-release --fromCheckout renamed to --from-checkout
- $METEOR_SAVE_TMPDIRS env var to not delete files.mkdtemp stuff
- release.latestDownloaded() now comes from tropohouse
we recognized that the cross-linking stuff in
Tropohouse.maybeDownloadPackageForArchitectures doesn't quite work so we
changed it to not quite work in a different way (which allows us to
leave downloaded-builds out of the bootstrap tarball and decrease its
size by 50%). will fix later.
springboarding happens infinitely because of build ids
have to manually bootstrap a tropohouse
fixed some other things:
- store package server token in correct domain
- copy files (eg packages pre-publish) with +x flags
- catalog.getReleaseTrack works
- don't pass release to uniload (Meteor.release will always
end up 'UNILOAD')
- fix building meteor-tool again
- stop supporting apps without .meteor/release
- merging unipackages with tools works
springboarding to warehouse releases totally not supported