<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 July 2015 at 20:56, Jonathan M Davis via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Monday, 13 July 2015 at 12:30:23 UTC, Iain Buclaw wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It need not be every compiler release.  Just releases that are shipped with GCC is enough to satisfy my requirements.<br>
</blockquote>
<br></span>
So, what you're looking for is that folks make sure that their libraries work with the version of gdc which was released with gcc? While I think that that's a good goal, I think that the reality of the matter at this point is that almost no one is testing their code with gdc (which is one reason why it's all the more important to properly unify the frontend across all three of the major compilers). And I expect that very few D library authors at this point are thinking about long term support. That sort of thing simply hasn't been the focus of the community as a whole, and most of the libraries out there are fun projects that someone did and put out there because they did it and want to be helpful, but they're likely not thinking about it like a product that needs to be maintained for folks who are writing long term projects. Something like vibe.d would likely be an exception, and from other posts in this thread, even it isn't thinking in terms of gdc or supporting anything other than the last few releases.<br>
<br></blockquote><div><br></div><div>Unifying the frontend only helps continuous integration and testing of upstream HEAD, to make sure that no upstream changes breaks a n alternative compiler backend.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, I think that to get what you're looking for is going to require shift of thinking in the D community. And part of that is really what Andrei has been looking for as he's talked about us becoming more professional (at least as far as the core devs and the official stuff goes). So, there's some push in that direction, but I don't think that it's sunk in all that far yet, honestly.<br>
<br>
One thing that you might consider is creating a wiki page which discusses the long term support for what gets released with particular distros and what folks should arguably be targeting if they want their libraries or programs to really work broadly rather than as a simple hobby project - e.g. you should target these releases of dmd, gdc, and ldc, because they're in these major distros with long term support. Maybe we can come up with some sort of recommended standard for what serious libraries should be targeting for support and encourage folks to follow that. As it stands, I think that most folks simply aren't thinking about it, and if they had some sort of framework to follow, they'd be more likely to.<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">Most projects seem to be erring in the direction of using TravisCI to test support.  I reckon it should be possible to tweak our D support in Travis to test specific GDC versions.  Whether or not users which to listen to it is up to them.<br><br></div><div class="gmail_extra">But of course, this is all low priority for the moment.  For now people have the luxury of being able to download GDC with newer versions of D backported to older GCC releases.<br><br></div><div class="gmail_extra">Iain.<br></div><div class="gmail_extra"><br></div></div>