JuliaLang just hit version 1.0 the other week

I and many other package maintainers have thus updated out packages to work with julia 0.7 (the transitional release) and 1.0.

In doing so, we've often created a backports branch where hot-fixes and other backported features can be made available to users of julia 0.6 (the previous stable release).

These backport branches are only going to be maintained for maybe the next 6 months at most, til most of the community has moved over.

In such a situation how important is it to maintain code quality in the backports branch.

A particular example: I recently added a new feature, which had 3 tests. I backported the feature, but I could only backport 1 of the tests, as the testing library feature I needed is not available for julia 0.6.

Is this ok? I feel like if this continues for ever it would be come increasingly hard to backport things without fear that I have undetectably broken something.
On the other hand, the work required to backport those tests seems hard to justify; since I am not going to maintain the backported branch for that much longer, and am only going to backport a small number of extra features. So it is a little bit of tech-debt that could be swept clean.

  • What kind of packages? Open source, freeware, or commercial? How large is the community you are talking of? 10 users? 1000 users? 100.000 users? Are there competing packages at the market? Without knowing these things, it is quite nonsensical to discuss the impact of not being backwards compatible. – Doc Brown Aug 21 '18 at 20:55
  • Open source, freeware, I think dozens of direct users now and maybe 100 indirect users, but it is growing. – Lyndon White Aug 22 '18 at 2:30
  • Well, if there is just a dozen of direct users, why not ask them directly how long they need versions of your package for older Julia versions? At least announce your plans in a prominent place and ask for feedback. You will get much better results from them than from some arbitrary strangers here on SE.SE. – Doc Brown Aug 22 '18 at 4:37
  • Because my question isn't about directly about supporting old versions. My question is about the importance of code quality in a backport branch that will only be around for at most 6 months. Related sure, but it would be weird to ask my users for advice on maintaining my code. – Lyndon White Aug 22 '18 at 4:42
  • 1
    @DocBrown for purposes of this question take it as if my users had all said "6 months, that is about right yes. We plan to have completely moved everything to 1.0 by then." Which is from the overall community what is going on. And for purposes of stack overflow, makes this a useful question for future readers. – Lyndon White Aug 22 '18 at 5:49

If I had a dollar for every time I heard "It will be dropped in X months, don't bother".....

But in your case you are the person who decides how long to maintain the version and how much work to put into it.

  • Have you got lots of paying customers on 0.6 who will not bother to upgrade?
  • Does it cost you lots of money to spend time on the old version?
  • What will you lose if the new 1.0 version isn't as good as it could be, because you fixed 0.6/0.7 instead of working on 1.0?

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.

  • @LyndonWhite: clearer now? Besides that, did you read the main part of my answer and what I am recommending here? If the time frame is shorter: better for you, you can earlier start using 1.0 features. If the time frame is longer, it gets more important to have your 0.6 package in a maintainable state. – Doc Brown Aug 22 '18 at 8:25
  • Yes, I think so. In my particular cases, that is what we (various people in various packages) were doing for the 0.3->0.4 change, and the 0.4-0.5, and the 0.5-0.6 change. And for 0.6->0.7-dev. The general trend in the community for the 0.6->0.7 (/1.0 which is 0.7 with deprecations removed), has been not to do that, but to branch and hopefully not need to backport too much stuff. I guess in part because the 0.7 release is transitional (released same day as 1.0, for purposes of making the transition), and that means 0.6 code won't normally work in 1.0 easily (but would work in the 0.7) – Lyndon White Aug 22 '18 at 8:34
  • +1, as it answered the general question and gives good insights. – Lyndon White Aug 22 '18 at 8:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.