buildids just change too damn much. oh no, you changed a comment in
random which is transitively used by templating which processes .html, I
guess you need to bump all the versions of all packages with .html?
that sucks. how about only changing it if the EFFECT of the build is
changed?
this does have some subtleties around platform-specific versions but we
think we have a good compromise
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.
We never really used it for anything, and it uses uniload in a
now-unsupported way (uniload in a built release now only can load a
predefined set of prebuilt packages)
Don't use it yet. Because the estimation function is so slow, it just
doesn't save any computations but rather brings new computations to the
table. This makes everything just slower.
Now there is a question about the correctness of big tests.
