Is there any more information how to create our own custom Meteor release? We would like to create a custom fork of Meteor with additional targets (from what I understand, that is necessary to support them). How does one make it so that if somebody clones our app (projects) and runs meteor that our Meteor release will be picked up to run the app?
It’s actually pretty simple if you understand a) that the publish-release command requires a .json file as a parameter, and b) what that file looks like. That was definitely the biggest hurdle in getting started, because it’s pretty much not documented anywhere.
Here’s an example of what it the release manifest should look like:
Honestly, I’m a little surprised there’s not a more active marketplace/trading of these manifest files. Maybe 2016 will be the year for that, and we’ll get back to having curated distros for industry verticals.
But I digress. The idea is that we simply want to run something like the following command:
meteor publish-release clinical.meteor.rc6.json
Which will then allow us to run this:
meteor run --release clinical:METEOR@1.1.3-rc6
Identifying Packages to Include
To get things published isn’t particularly difficult. Just requires a bit of busy work. In particular, keep in mind the following points:
Every package in the release has to be published and on Atmosphere.
The .meteor/versions file of an app is a particularly good place for finding all the necessary packages and versions that should go into the release.
After that, it’s a matter of figuring out what you’re willing to support, what you want to include, etc. Here is a partial Venn Diagram of what the Clinical Release is currently working on; and should give you a general idea of how we’re going about the decision making process of what gets included.
It’s easy to get a meteor helloworld command working, but after that, I felt it was easier to just create a separate node app to test out commands. Which is how StarryNight came about. It’s something of a staging ground and scratchpad for commands before trying to put them into a version of the meteor-tool.
Speaking of which, I created a small utility for creating the release manifest, which is available in StarryNight.
OK, is there a way to get that JSON file for official Meteor release? Why is that not in the repository? Or is it? I think it would be a great place to start. Especially because I am planing to more or less follow the official release, just add more targets.
Also, is it possible to “pin” a project to a release? So that it is not necessary to run meteor run --release clinical:METEOR@1.1.3-rc6 but one could just run meteor, but because the project was created with a custom release, it would work? Would changing .meteor/release file to clinical:METEOR@1.1.3-rc6 fix that?
How does api.versionsFrom then work? Does it base it of that release? So would api.versionsFrom('1.1.3-rc6') be equal to api.versionsFrom('clinical:METEOR@1.1.3-rc6')? Does that even work?
Great questions. I’d be interested to see the manifest file also. Hopefully, somebody from MDG can provide a link?
From my preliminary tests, yes and yes. To the point that there are some mix-and-matching rules which I don’t fully understand. One thing I know is that I’ve had to publish all the packages in the release with the previous Meteor build.
That is, a release can’t be published if it has packages with api.versionsFrom() that specify a later Meteor build. We had some packages published with Meteor 1.2 that had the ecmascript package automatically installed, and that broke our clinical:METEOR@1.1.3-rc6 release. So we had to go back to those packages and publish them with basic Meteor 1.1.3.