We're very careful with changes and give thorough deprecation warnings. When you upgrade and the meaning of something that you're using is going to change in the following version, you will get a warning to change it now, with specific detail of the new spelling of that feature. So as long as you don't skip major versions, you're safe. Corollary: don't skip major versions. Even if you're upgrading from 0.4 to 0.7, you'll want to upgrade /through/ versions 0.5 and 0.6 instead of skipping them.
Aside: implementing deprecations is often harder than implementing new feature themselves. We put in the effort because it is absolutely critical that people's code never just silently change behavior. Syntax and variable scope deprecations are particularly hard to implement, but all of the changes in 0.7 do have deprecation warnings – some of them with absolutely crazy implementations that we're very excited to get to delete when we release 1.0.
It's not so bad really – having done it a few of times on fairly large code bases. Upgrading a project for a new Julia version is very straightforward: change the julia version, run your tests, and making any changes that warnings tell you to make. It's about as difficult as fixing compiler warnings in C – it's tedious but not hard.
Keep in mind that in the future this statement would be something like: if you have code that was written for Julia 1.x and want to upgrade to Julia 3.x, then you should upgrade through Julia 2 instead of just skipping it. This does not seem terribly unreasonable.
That's only if you haven't touched your code in 2 years or so, and is also just an issue with early adoption. There's a reason why Julia wasn't labelled v1.0 yet, but post-1.0 is where the syntax is stable.
The forthcoming Julia 0.7 release will provide warning messages for important (and breaking) changes that the community has been clamoring for. I don't think users are "worried" so much as they are planning to review and update their code accordingly. For example, I don't expect my existing 0.5 code to work without substantial revisions. This is the last window to improve the language proper before the 1.0 release, after which users like me will expect stability.
Just FYI as noted above, 0.7 is the harbinger of 1.0. It is functionally equivalent to 1.0 except deprecation warning, serving essentially as a migration version. So while not out yet, 1.0 is around the corner!
Aside: implementing deprecations is often harder than implementing new feature themselves. We put in the effort because it is absolutely critical that people's code never just silently change behavior. Syntax and variable scope deprecations are particularly hard to implement, but all of the changes in 0.7 do have deprecation warnings – some of them with absolutely crazy implementations that we're very excited to get to delete when we release 1.0.