Update 1.2.1 for faster re-builds

[TomFreudenberg]

See PR https://github.com/meteor/meteor/pull/5747

which was merged to current 1.3 as https://github.com/meteor/meteor/commit/a576bda03a584dda3ac5e6200bb207008cefd482

[TPXP]

Honestly, backporting changes does not seem appropriate to me. In my opinion, we should better provide 1.3 beta releases (one branch for all the 1.3 releases?), to stick as much as possible to upstream.

[TomFreudenberg]

Hi Thomas ( @TPXP )

you are right, I would not try to backport and I am already on the beta track for 1.3 on ARMs.

If I got it right, the linked merge just touches 2 files in a minor way. If this would drastically reduce rebuild times when running meteor on small boards, wouldn't this be a benefit?

Thanks for some more feedback Tom

[TPXP]

Hi Tom,

I definitely agree on the fact that this will be a great improvement, but why not release it with 1.3? This seems more logical to me, and more in accordance with upstream. It will avoid to have to ask "Hey! Which 1.2.1 version are you using?" if an issue pops up. Furthermore, it will keep the things clear for our users, who often refer to the version they use with the release number instead of the latest commit hash.

I understand it can seem a bit too rigorous, but I think we should be as close as possible to upstream because this makes it easier to track changes. I mean, even if it is a small change, it messes up a little bit more the things, and opens the way to deeper changes that are going to make it harder for our users to get help as we change things on our own.

Upstream is a kind of reference, that's why I think we should avoid any unneeded change, even if minor!

Thomas

[TomFreudenberg]

Hi Thomas

I normally would agree to your upstream policy (as close as possible) but I just think about that feature before this big coming 1.3 update from meteor. 1.3 will change meteor in many many parts so that 1.2.1 might be some long existing release for a number of users / developers.

That is the only reason why I think about to include that patch. If it would be just 1.2.2 which is in front of us, I never would think about some backwards patches.

Hard to take the right decision

Tom

[TPXP]

I don't think the changes are that much radical, at least the changelog does not mention breaking changes (except maybe Cordova, but is it going to change a lot of things on our side?). So in my opinion porting 1.3 should not take a long time. Furthermore, there is no urgent need for this (nobody actually asked for it..), so why not waiting 1.3?

Anyway creating a 1.2.2 pseudo release seems to me as a very bad option because it will really introduce a confusion between our users and upstream users. I cannot help but imagine some comments on help requests like "Oh, you got 1.2.2. How is that possible?", making it - again - harder to get help.

Maybe we can find a compromise by providing a patch file, that the user can apply? This way the user is aware of this, so he knows what he is doing. ☺

[TomFreudenberg]

I will check again the changes to 1.3 if I have interpreted too excesive their changes ... If so, I would really like that ;-) and we will just build the next 1.3

In addition to just mark another hint in section "README/Good to know" would be far enough for this patch (like a cherry-pick)

[rjhllr]

I think this issue is less relevant / might be closed with 1.3 having been released today and I think this repo's target will be to follow up with building that instead of focussing on 1.2.1.

[TomFreudenberg]

As we currently working out the 1.3 - I will follow @TPXP and @rjhllr and do not invest in that issue. Anyone like or need please check out 1.3 from our fork which will be available soon.

Thanks supporting us.