<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-10-09 14:57 GMT+02:00 Mario Blažević <span dir="ltr"><<a href="mailto:blamario@ciktel.net" target="_blank">blamario@ciktel.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] You can do this with no extra tooling, the only extra work is to run seven commands instead of one at publishing time:<br>
<br>
   git checkout ghc-7.8<br>
   git merge master<br>
   cabal upload<br>
   git checkout ghc-7.10<br>
   git merge master<br>
   cabal upload<br>
   git checkout master<br></blockquote><div><br></div><div>Let's pray that no merge conflicts will happen. Furthermore, you've omitted the "git push"s to github to let Travis CI tell you what you've forgot. You should better do that before an upload. Ooops, and you forgot to tag the release, too (I mean 7 tags)...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] I really don't see what could possibly cause all that complexity. Conflicts between different GHC branches and master development branch should be minimal, with any care.</blockquote><div><br></div><div>For toy stuff you might be right, but in any larger project I've seen in the last decades, keeping branches well maintained *is* non-trivial. Normally you already have branches for different releases of your SW you still have to maintain, and with the proposed approach you would effectively multiply the number of those branches by the number of supported platforms/compilers. Much fun proposing that to your manager... This might work if you have only linear development and few platforms, but otherwise it won't scale.</div><div><br></div><div>Furthermore, having #ifdef-free code is a non-goal in itself: The goal we talk about is ease of maintenance, and as it's proposed, it makes a maintainer's life harder, not easier (you need much more steps + bookkeeping). And the merges e.g. only work automatically when the change in the #ifdef'd code would be trivial, too (adding/removing lines, etc.), so git doesn't offer any advantage.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In a nutshell: IMHO having #ifdefs in the code is the lesser evil. If somebody has a better, actually working idea, he can probably become a millionaire quickly by selling this to the industry...<br>
</blockquote>
<br></span>
    The industry can be remarkably reluctant to take up a new idea; nobody has ever been fired for using #ifdef.</blockquote><div><br></div><div>If you can provably speed up development time and/or release cycles, selling new ideas is easy: Nobody has been fired for reaching a deadline too early. OTOH making some work easier and at the same time other work more complicated (as is the case in the proposal) will meet some resistance...</div></div></div></div>