Skip to content

drop support for old compiler versions #141

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
SingingBush opened this issue Nov 24, 2017 · 1 comment
Closed

drop support for old compiler versions #141

SingingBush opened this issue Nov 24, 2017 · 1 comment

Comments

@SingingBush
Copy link

DMD is now up to version 2.077.0 but mysql-native is still setup to test against dmd as far back as v2.068.2 (that's 10 releases).

Please consider dropping support for older compiler versions. Supporting v2.074.1 up would be enough. It's an unnecessary maintenance burden. It would also help shorten the huge CI build time.

SingingBush added a commit to SingingBush/mysql-native that referenced this issue Nov 24, 2017
@Abscissa
Copy link

Abscissa commented Dec 2, 2017

(I'm going to address the CI build time separately, down below.)

One of the development principles I try to adhere to is: The user's experience trumps the developer's experience.

As a corrilary to that, I firmly believe that breakages (that includes dropping compatibility) must come with sufficient justification. In other words: dropping compatibility is a concession, not a feature (We do it because we need to, not because we can.)

Mysql-native already works with DMD's down to v2.068. Even the fix I just made to work around that weird bug in v2.074 (which only affected mysql-native's the tests, not even the lib itself), once I was able to actually get back to mysql-native, that fix only took a mere few minutes. So, for now, the maintenance burden of keeping support is negligable and dropping support would amount to "because we can. F*** the user I matter more". I'm not going to do that.

If/When the library has a need that breaks an earlier compiler, and cannot be handled trivially, that's when it's time to sit down and re-evaluate whether support is worth maintaining or finally dropping.

As for reducing the travis build time, I agree that would be nice, all else being equal. Especially now that the osx-testing is in and doubling the number of jobs per build (and it looks like osx jobs are running a little slower than their linux counterparts, making the overall build time that much worse). But there are other avenues for reducing the travis build time. For example, I'm not sure that it's necessary to test every supported compiler on both lin and osx, much like how it doesn't bother repeating the "other versions of db server" for every supported compiler.

(Oh, and FWIW, it should be noted that those couple 3+ hour builds from today were because travis was having some problems with their osx VMs at the time. I was watching those builds run and the linux tests finished up at about the same rate they always did. Then the osx hiccups brought the rest of the build to a complete crawl.)

In summary, the project's policy is that compatibility will be dropped only when neccesary. And it's not necessary at this time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants