Feel free to use Telescope for testing 
2 Likes
It’s depend on the type of packages we build.
May be not all packages needs to work together.
Some can be used as libraries. May be some one needs to manage it.
I hope the community itself do it. If package A and B needs to work together.
We can open issues on both repos and let things happen.
One thing I saw is the useraccounts flow-router support. A lot of people have raised the voice for adding flow-router support for useraccounts. Someone did a initial hack and it’s polished now.
May be there are more stories like that.
Most our packages works together pretty well.
1 Like
There’s not a whole lot of documentation on it, as it was only introduced in 0.9, and it takes quite a bit of work and planning to successfully put a track together. Start with the official documentation, and the PracticalMeteor tutorial:
http://docs.meteor.com/#/full/meteorpublish
http://practicalmeteor.com/using-meteor-publish-release-to-extend-the-meteor-command-line-tool/
Ronen’s tutorial goes through how to hack on the Meteor Tool itself; but one doesn’t need to go through quite all the trouble of creating a custom tool, if the only goal is to put together a track with packages that work together. Basically, you just need to run the publish-release command with the --create-track flag.
meteor publish-release --create-track release.json
meteor --release foo:METEOR@0.x.x.x
The biggest mystery is the format of the release.json file, which will look something like this:
{
"track":"foo:METEOR",
"version":"1.2.3",
"recommended": false,
"tool": "foo:meteor-tool@1.2.3",
"description": "Foo Meteor for You!",
"packages": {
"autopublish":"1.0.3",
"autoupdate":"1.2.1",
"base64":"1.0.3",
"binary-heap":"1.0.3",
"blaze":"2.1.2",
"blaze-tools":"1.0.3",
"boilerplate-generator":"1.0.3",
"callback-hook":"1.0.3",
"check":"1.0.5",
"ddp":"1.1.0",
"deps":"1.0.7",
"ejson":"1.0.6",
"fastclick":"1.0.3",
"geojson-utils":"1.0.3",
"html-tools":"1.0.4",
"htmljs":"1.0.4",
"http":"1.1.0",
"id-map":"1.0.3",
"insecure":"1.0.3",
"jquery":"1.11.3_2",
"json":"1.0.3",
"launch-screen":"1.0.2",
"livedata":"1.0.13",
"logging":"1.0.7",
"meteor":"1.1.6",
"meteor-platform":"1.2.2",
"minifiers":"1.1.5",
"minimongo":"1.0.8",
"mobile-status-bar":"1.0.3",
"mongo":"1.1.0",
"observe-sequence":"1.0.6",
"ordered-dict":"1.0.3",
"random":"1.0.3",
"reactive-dict":"1.1.0",
"reactive-var":"1.0.5",
"reload":"1.1.3",
"retry":"1.0.3",
"routepolicy":"1.0.5",
"session":"1.1.0",
"spacebars":"1.0.6",
"spacebars-compiler":"1.0.6",
"templating":"1.1.1",
"tracker":"1.0.7",
"ui":"1.0.6",
"underscore":"1.0.3",
"url":"1.0.4",
"webapp":"1.2.0",
"webapp-hashing":"1.0.3"
}
}
There’s also starrynight command that will help generate a release track. Run it from within an application that has all the necessary packages added that you want to use as a baseline for your track.
starrynight generate-release-json
After that, it’s just a matter of going through dozens of packages, and doing the tedious work of auditing them and making sure they work together.
The last missing piece for all this to work really well is a way to list/search tracks on Atmosphere and the meteor search tool. Hopefully we’ll see something come along the next time they do an iteration on the packaging tools.
2 Likes
isn’t this an example of a track?
I think a track should be used via meteor create, like:
meteor create test source:meteor-boilerplate
Some code to show how to use the packages together, and a brief tutorial on the track would be mandatory to help beginners.
1 Like
Well, the meteor-boilerplate could certainly be turned into a track. I don’t think it is one right now. But it’s a good candidate for doing so.
And, yes, it would be very nice to see Atmosphere support a Readme for tracks, so we could put the documentation you describe in a place where people will expect it, and will actually find it.