I just wanted to chime in for those who think that 1.2 is something that will immediately break their app. I think it’s actually really solid.
I have two prod apps that I upgraded to 1.2 with 0 issues. The upgrade was great.
A big part of this is because those apps only have 1 or 2 third-party packages. I think this is something the Meteor community can learn from the Ruby Community as they’ve had the same growing pains with upgrading.
There are so many gems that can help you get started quickly… but they come at a cost. That upfront speed is traded for flexibility later. You’re now dependent on the gem maintainer to make sure everything is working well. Multiply that by 20 and you now have a real constraint when you need to change your app (new versions or customer requirements).
If you’re only using 10% of the package, sometimes it’s easier to just write it yourself or copy code from the package (with tests!). Most of the time your version will be more flexible with inevitable customer changes in the future.
To sum up, I think people are giving MDG an overly hard time with the 1.2 upgrade. Part of your upgrade pain is self inflicted (myself included as I have apps that can’t upgrade easily).
Agree you can upgrade without too big issues. And if there are issues most of the time they are not about core code with issues.
About those packages I don’t fully agree. Yes you are right but it’s also a bit of insight needed in the packages market. You can use packages like FlowRouter without any hassle. Also accounts packages do quite a good job. But you need to know that. Part of this knowledge gets into the guides @sashko is starting which makes it easier to get insight. Also the initiative to test packages with the new Meteor versions is very useful to further prevent those issues.
Selecting the right packages
For other packages it might help a lot to check out their GitHub account very well to see the activity. If you have a very active package with issues, pull requests etcetera (also look if they get merged!) then you won’t have big issues OR they will get fixed quite soon because people are active.
But yes too much is too much, that’s totally correct.
@lucfranken That’s a great point. Observing the activity of the package matters if you plan on upgrading to the latest core release.
IMHO one of the reasons FlowRouter is so stable and easy to upgrade is because Arunoda does a great job of de-coupling. Something I wish more Meteor packages did, eg. use of the Unix philosophy of doing one thing and doing it well. This allows us to compose packages from these small core packages. (Reaktor is a great example, using FlowRouter and ReactLayout to create a React specific router).
I think testing popular packages would be great too. I also test the functionality of major packages I use to ensure they don’t break unexpectedly (like the permissions packages, those are critical). These are basic smoke tests to make sure a regressions doesn’t happen.
IMHO often there are also not or not clearly defined dependencies to used packages. During our developments we are starting at least each app with its (lets say) personal base package. Just to fix define all packages AND versions we need for this app. Also we are running meteor command all the time through an alias with given --release.
Whatever might change outside in the world - it won’t touch us. When there is the time for an update, we create a new branch and doing the meteor and/or package updates. This is a thread in parallel until its finished and we got and commit all necessary changes. In addition, we do not use any magic packages which are not available on github nor which we do not understand. That is in case of missing maintainer effort to be able to patch or change the package for our and systems needs. At least we are responsible to our customers and have to fix things ourselfs.
In all the discussions here, I am feeling a bit funny about some developers attitudes. We are all knowing that new things will make effort normally in IT. Every time something is working out of the box, I am really excited - especially when some update will make our solutions better (more stable, faster, smarter …) without having personal effort in it.
Meteor has left us all the time we are using it (0.6x was first) in a state, that we could full fill our promises and agreements to our customers. Thats great. Also we were able since using Meteor to make nifty solutions in a very short time for our customers. Thats great, too.
So I think, if anybody will make himself an update-plan when new elements are available, it would be possible to update without headages.
TLDR: Fix define the versions of meteor and used packages inside your apps and during development to a known and controllable state. Give yourself and team a plan and time resources to go through the update process.