I don't know Julia enough to know if the following can be applied to your situation in full, but to give you a general answer for comparable situations: IMHO it is a good idea to avoid maintaining two different code bases of the same package over several months.
If the majority of your users is still using Julia 0.6, and you expect them to do so over a period, of, say, six months, then
do your main development on 0.6 as well
offer a feature-identical version for Julia 1.0, but resist your wish to use any new features of the language (at least, for the timeframe you want to support 0.6).
The goal should be to have one code base with >98% lines of code identical for both environments. The files should be identical. Don't maintain two branches in your version control system, just one, from where you can build the 0.6 and 1.0 version of your package! You may have to maintain different build configurations for 0.6 and 1.0, of course. And maybe you will need a little bit of conditional compilation to work around some limitations if there is definitely no other way (but you should try to keep that portions of the code small).
When you go that route, the question of "backporting" and "different code quality" will simply not arise. Just don't fall into the trap of believing just because "1.0" is now available, you need to use "the latest and the greatest" version of the environment immediately. If some of your users can or need to wait for some months before switching completely, I am sure you can, too.
Let me tell you about some personal experience. Our team used this strategy once to port a >100kLOC C++ program from an older UI 16 bit framework and an old 16 bit Borland compiler to a newer 32 bit UI framework using a new MS compiler, in a time frame of roughly a year. I don't think we could have managed the task if we had tried to maintain a "newer version" of the product in one code base, and the older one (with "backporting features or fixes") in a second code base.
Instead, we managed it to keep the code base in a state where we could compile the identical source files with both compiler & library environments. We had to use some tactics like
providing some wrappers for the old APIs in the new environment (like a String wrapper around a std::string)
mirroring the common source files into a second folder using hard links, to have compilation folders separated, but when editing the a file in one folder, having "the other file" automatically changed as well
avoid the usage of any new C++ features, or direct use of newer libs (except through wrappers) for the transition period.
Of course, you will have to transfer these ideas to your environment and your situation, but I hope the general strategy becomes clear.
