Get Meteor to use code from this repository for Blaze distributed with Meteor releases

[mitar]

No description provided.

[laosb]

For now, Blaze doesn't really have a separated versioning. Should we have an independent versioning system?

[mitar]

I think it does and I also think this was one of the core goals with splitting some (all) packages from Meteor.

[laosb]

Every Meteor release gets a bump. That wouldn't be ideal for a separated package.

[mitar]

I think that would not be needed anymore, this is one of those changes they are working on.

[MiroHibler]

I don't think MDG should ship Blaze (or any view layer for that matter) with Meteor in the first place. I'd rather make it all optional as they do now with React since v1.3 for example.

[mitar]

I think they will have to do so for foreseeable future (at least until they go to Meteor 2.0). And also we will have to keep backwards compatibility for that purpose. We can (as a community) go and do Blaze 2. But we and MDG also have responsibility for current users using Blaze 1.

In any case that's their call to make and I am operating on what they have expressed until now (Blaze gets extracted out, gets its own versioning, Meteor ships with that Blaze). If you hear other plans, please do report them here. :-)

[MiroHibler]

I'm just pessimistic by nature and MDG has been known for abruptly changing their mind ;)

[mitar]

OK, let's be more optimistic in the future, there is enough bad feelings around Meteor already.

So, let's get community to go through tickets and see which are still relevant. This is only on us. If you are more optimistic about community, then feel free to organize this part.

[MiroHibler]

I was (trying to be) sarcastic ;) I wouldn't be here if it wasn't for my optimism! ;)

Lets hear what community has to say.

[mitar]

Sorry, a bit long day. Didn't catch that.

[brown2rl]

@mitar is there anyone from MDG watching this repo? I think Blaze 1 has some serious potential. It would be nice if we could add an option like

$ meteor upgrade blaze

Essentially the proposed script combines both requirements above, and would pull from the official repo to replace Blaze 1

[tcastelli]

+1 Blaze has some good potential inside and I think a symlink to this repo in their own repo would be quite useful to forget about shared versioning system and dependencies.

[mitar]

They are, you can see them here. :-)

[brown2rl]

@mitar ok, cool. let me know what i can do

[zol]

A loose plan for 1.4 is to depend on Blaze via the app's package.json. This will be the point at which we're naturally able to use this repo completely independently.

[mitar]

@zol, @benjamn: What does this comment mean for the future of this repository? It seems that community involvement in Blaze will again suffer and not move anywhere. I see that there are some potential changes to Blaze repository going in as fixes in Meteor repository, not here. I really worry that this delays of switching Meteor to use this repository will make put all this into a limbo and Blaze will not be able to move anywhere, which will effectively kill it. Not just that MDG is not investing time into Blaze anymore, but now even community seems to not be able to do so.

Can I propose a intermediate solution? Make meteor repository use git submodules to pull these packages here into the main repository and let's start working here on Blaze as a community. Later on, when you finish with NPM integration, we can improve things.

But waiting for NPM integration and everything else seems like putting all those plans we had for Blaze and community stewardship of Blaze in jeopardy.

[ramezrafla]

Agreed, many of us depend on Blaze and are not switching any time soon. There has to be an alternative when MDG changes its mind (again!)

[zol]

@mitar Meteor 1.4's package unpinning feature will allow us to completely move blaze development over to the community repo without waiting for npm integration.

[aadamsx]

Meteor 1.4's package unpinning feature will allow us to completely move blaze development over to the community repo without waiting for npm integration.

Why wasn't @mitar aware of this before so we could have moved forward on this project? Was/is this the only roadblock to moving forward?

[mitar]

@zol: Great to hear that. So, could we make this transition happen with 1.4 release? Can you then remove the code which is in this repository from Meteor repository? I think this would be a great signal that everything is ready to start in this repository.

So for now then we would keep Blaze pure-Meteor packages and continue with this until Meteor has better NPM integration.

So my proposal for steps is:

• code is removed from Meteor repository
• a Meteor 1.4 release comes with community (this repository) packages for Blaze
• community in meantime transfer all Blaze related issues to this repository
• we establish a stand-alone site
• and stand-alone documentation

How does this sound?

(edit: I wrote "related packages", but it should be "related issues")

[aadamsx]

• code is removed from Meteor repository
• a Meteor 1.4 release comes with community (this repository) packages for Blaze

Who will make the final decision here? Who would carry out the tasks? How can we get the decision makers to actually make a decision before 1.4 is released?

• community in meantime transfer all Blaze related issues to this repository

What are the tasks involved and can this be broken down and assigned or is this something that must be done by someone with deep knowledge of Blaze and related packages?

• we establish a stand-alone site
• and stand-alone documentation

These can be started by anyone. But the documentation should be pulled from somewhere or should original documentation be built?

[mitar]

@aadamsx: Most of this things have already been discussed in other issues. I would invite you to check about site and documentation in those issues. Also process on transferring Blaze issues (not packages, that was a typo) have already been started.

About the governance. I think for now I would first like to see who is at all interested in contributing. And if can operate with rough consensus. If it becomes complicated, we can have a longer discussion. For now I would simply publish packages from this repository and I would like that this is possible - make one release where there are not really much changes (maybe just what is already there + fix for Chrome, meteor/meteor#6793).

[laosb]

Is the code in this repo up-to-date?

[mitar]

It should be. We should of course check that. But when I was last checking it was.

[aadamsx]

Meteor 1.4 is has been released.

@mitar is there any prep that needs to take place in order to get started using this community repo for Blaze?

Do you have guidance on using the new unpinning feature that will allow us to completely move blaze development over to the community repo without waiting for npm integration? ... Using Meteor 1.1 or another target release of Meteor?

[mitar]

We would just release Blaze as a Meteor package. But we first have to get permissions to do so. So, @zol, what's the plan here?

[zol]

@tmeasday was looking into whether there would be any technical ramifications of removing the package sources from meteor/meteor and just giving you publish permissions on the blaze package. @tmeasday - can we just go ahead with this now?

[tmeasday]

Yeah, we talked about this a little bit. There are a couple of implications of removing these packages from meteor/meteor, assuming that means that we no longer publish blaze as part of the release[1].

1. The boilerplate includes a dependency on Blaze. This is easily fixed by just putting an @version here and (ideally) keeping it up to date with Blaze releases.

2. A bunch of internal packages depend on templating (mostly accounts related things). I think we can just switch them to again @version depending on it though. As long as Blaze follows semver, I think we should be OK to set this to something that makes sense now and not really touching it unless changes happen w/ Blaze.

3. Third party packages that use api.versionsFrom(RELEASE) and depend on blaze or templating without using a version constraint. This is probably the biggest issue. If Blaze is no longer in the release, then the semantics of that changes (from "blaze >= version specified in RELEASE" to "any blaze version"). But that would only bite people if they update RELEASE to be >= the release we remove blaze (let's say 1.4.1, for argument's sake).

   We would have to make it clear to package authors that they should specify blaze versions.

[1] A simpler option is to just use a submodule and keep including the latest version of Blaze in every Meteor release, but this seems like a half-way house. Perhaps we can keep it as a back up plan in case any of the above are deal breakers.

What do you think @mitar / et al?

[tmeasday]

There's also a minor philosophical problem that this list of packages includes static-html, which feels like it should remain in mainline meteor. But I'm not sure how to disentangle it from these blaze/spacebars packages.

[mitar]

I think the full change to @version seems OK.

Could we maybe change api.versionsFrom to have a more reasonable behavior? Like latest Blaze version? Or maybe we could even hard-code some exception for Blaze?

[tmeasday]

I think if we were going to do that we should probably just go the whole hog: if you depend on a non-core package from another package (where the list of core packages is shrinking and will continue to shrink over time), you have to specify some kind of version constraint, or there's an error.

[aadamsx]

Any progress on this front?

[tmeasday]

meteor/meteor#7633

[tmeasday]

Hi! These packages are now gone from the mainline meteor repo! meteor/meteor#7633 🎉

[tmeasday]

(See also #56)

[mitar]

Yea!!!

OK, we should then probably create now a Blaze Meteor development team, and get it access to publishing packages from this repo to Atmosphere.

[mitar]

And how we should go about updating changelog in meteor about Blaze related things? Or should we just maintain it here?

[tmeasday]

1. Yeah, create a MD organization and I'll give it publication rights.
2. Well meteor update will no longer treat Blaze any differently to any other non-core dependency[1], so people won't necessarily get Blaze updates w/ Meteor releases. OTOH people might not think to check a different changelog if they do take a Blaze update. I'm not sure the best way to get this message across, but I think a separate changelog is still best.

[1] Not 100% true because some core packages depend on these packages but you can safely ignore that in thinking about this.

[mitar]

I created blazecommunity.

OK, then we will handle one changelog in this repository. Yea!

[tmeasday]

Maintainer added!

[tmeasday]

Let me know if you have thoughts on how best to tell people to look at the Blaze changelog.

[mitar]

Yea!

I think we should just make an entry in Meteor's changelog to point them here and this is it?

One more question: how will documentation (http://docs.meteor.com/) be done now? Is it pulled from here? Or should we setup something independent?

[tmeasday]

I think we should just make an entry in Meteor's changelog to point them here and this is it?

I mean, definitely this, but I'm wondering if there's more we can do. Something prominent here: https://atmospherejs.com/meteor/blaze would be good too I think.

One more question: how will documentation (http://docs.meteor.com/) be done now? Is it pulled from here? Or should we setup something independent?

For now, yes, it will pull from here (as I bump a submodule). If you set up something independent, we should point people there though, given the decoupling of the releases.

[mitar]

I opened #57.