the "We pass" comment was stolen back from devel
basically, whenever doing eachUsedBuild, you really want to pass in the
arch of the overall compilation (or for plugins, the host arch), not the
arch of the unibuild you happen to be sitting in right now. because if
you're sitting in a generic "os" unibuild, it won't know whether to use
os.mac or os.linux or whatever if you pass in "os"!
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
This means that standard-app-packages in your app is enough to get
'.html' and '.css' processing working, and apps work again.
This is a bit of a hack: we'd rather just make build time deps
directDependencies contain implied dependencies too instead of sticking
the entire constraint solver output in the database.
Unipackage always has all direct deps now, but `checkUpToDate` and
`getBuildIdentifier` only consider the set of direct deps that provide
plugins.
Catalog versions now get updated during initialization, so after the
catalog is initialized, you can look up versions that include build ids.
We used to keep the `packageDirectoryForBuildInfo` of every package that
a package directly depends on in its buildinfo.json; if direct
dependencies change, then we might need to rebuild because they could
have registered or unregistered a plugin. Now we just keep the package
name and version (including build for our local packages) of our direct
dependencies.