Change LDC version to 2.080.0 #2673
Conversation
|
Is there a way to make it clearer that e.g. LDC 2.x.0 is using the frontend of DMD 2.x.3 ? |
|
I thought about releasing a |
CMakeLists.txt
Outdated
| @@ -62,16 +62,12 @@ endfunction() | |||
| # | |||
|
|
|||
| # Version information | |||
| set(LDC_VERSION "1.10.0") # May be overridden by git hash tag | |||
| set(LDC_VERSION "2.080.0") # May be overridden by git hash tag | |||
There was a problem hiding this comment.
Since these are now identical, maybe this can just be set to DMD_VERSION? I guess you want the flexibility for the two to vary?
|
OK, so we number the LDC version the same as the frontend version it's based on? That sounds good. |
|
-1 from my side, as I think this will only lead to confusion with patch releases and skipped versions – i.e. I think the version numbers should only be synced if the two compilers are released as part of a single release process. Since I haven't been managing the releases for a long time, my opinion probably shouldn't carry too much weight, though. |
That's a very good point. |
|
Yeah okay skipped versions are confusing indeed, so how about |
|
OK, if going forward with this, let's not follow the DMD patch number. Something related: do we want to release every two months, or do we just skip version numbers? No need to rush this versioning change, let's let it simmer for a bit? |
The release overhead has gotten very small, except for the manual armhf and Android packages, so I don't see a reason not to try to keep up with DMD's pace as long as I don't run into a burnout or someone else takes stuff off my shoulders. The upstream changes accumulate anyway, so releasing every 2 months instead of, say, 6 months, makes sure stuff can be tested and fixed earlier. I leave it to the user to decide his migration pace.
1.9 => 1.10 would provide a nice opportunity IMO, but I'm okay with delaying it. |
747 downloads for 1.9-beta1 in a single week (and 368 for 1.9 final in ~36 hours). Debian/Ubuntu ship with 1.8 (and build all D packages with it). So I'd say testing does happen, and I don't recall that many issues originating from Weka in the first place. |
|
Can we go ahead with this? As @kinke said, the 1.10 numbering might require some adjustment, so no reason not to make the 2.080 adjustment instead. As for patch releases, his proposed solution of having a different patch version for LDC solves it: the next official release would be LDC 2.080.0 with the eventual DMD 2.080.1 frontend, as reported by the compiler. If we need to, we could always update that LDC patch version independent of the dmdfe patch version. |
kinke
changed the title
|
I'm all for the change, as I somehow don't fancy |
|
The amount of downloads doesn't mean much. I am talking about in-depth testing with a complex codebase, where minute semantic details matter, where performance matters, where ABI details matter, etc. Some evidence that such numbers do not mean much: DMD has been downloaded a lot since 2.040 but it has not been tested very well at all: only recently a bug was found with bad codegen for
Releasing final versions is not needed for testing; on the contrary, testing should happen before, not after, a release. If we keep a very high pace of releasing, there is not going to be a well-tested release; it'll just all be ok-ish releases that each have their own sets of new bugs, and the user only has the option to migrate to an ok-ish version. The release of 1.9.0 happened after one week of beta. To me, that means it is mainly untested (and even some of our own core CI systems are failing). We are currently moving closer to "hobby-like" style of development, and I believe we can do much better than that.
regarding Weka: I meant it as an example of a complex codebase where testing a new compiler takes much longer than a week (in part because thusfar, workarounds must be introduced to make the code compile at all with a newer compiler due to regressions or other issues). But plenty of very fundamental issues were found at Weka, in the DMD frontend, in Phobos, LDC, and LDC's druntime.
But I didn't :( I wrote to the maillist instead: |
Please announce the plans for a new release with, say, a week's notice, such that the other developers of LDC have time to consider. |
|
@JohanEngelen, I agree with most of what you said: this release schedule is too rapid and doesn't give users time to shake out bugs. However, switching our version numbering to match upstream is not related to that. Has Martin addressed your numbering concerns with this latest pull? |
The one week was shorter than the usual 2 weeks, but the reasons were DConf & 2.080 being almost ready. Still, if there are no reported issues after 700 downloads, I take that as a sign that there are no obvious serious regressions.
In an ideal world, yes, but we all know this largely isn't happening, at least not if people know the final's gonna be out 2 weeks after the beta. We don't really test LLVM betas ourselves and have only recently been able to test DMD betas (and yes, some of my fixes made it in time into 2.080.0). With CI builds being available all the time, there's no real blocker for users to test latest LDC, but yeah, hardly gonna happen. Just out of curiousity, has there ever been an LDC release Weka was able to test thoroughly before it actually got released? I totally understand that for commercial users, non-0.17 'LTS' versions would be very convenient, but as such I see that as their (and other interested parties') responsibility to do something about it - and mainly regarding DMD/druntime/Phobos, as OTOH the only LDC-specific regression lately was the install_path shared lib issue on OSX.
As you know, I didn't just keep up with DMD's pace, but was actually faster so that we caught up and are now as good as even, while fixing other things as well. It's clear that this wouldn't have been possible if I had to wait for weeks for the PRs to be finally reviewed & merged by someone else; I guess that's what you're trying to say. Anyway, I think the end result is definitely worth it, hardly any reports of new serious LDC issues and D enthusiasts should get used to a new LDC beta coming out a few weeks after the DMD release, so that I don't have to read 'can't use LDC coz it's lagging several versions behind' anymore. I firmly believe this uniformity is important for the D ecosystem, will increase LDC usage/test coverage (wrt. bandwidth - people exporting naked functions, using identical labels in different function overloads...) and reduce frustration (Mike: 'will have to wait for 4 months for 2.081 language change to land in LDC' - nope, will most likely be 2 months from now, still a lot, but half).
Will do; I hoped |
|
Thanks for being so awesome with LDC, @kinke! |
sorry for the thread hijack. I think it's not so bad to align the version numbers, but it does lock us to that versioning scheme. Our current version is quite easily converted to dlang version (+70), but it is indeed often annoying to say "LDC 1.9.0 (dlang 2.079)". |
Yes. 1.8.0 was (somewhat) tested before release, currently fully passing their test suite (not tested on full full full test suite yet). Little longer ago, if you remember the
Yeah, a lot of work! DMD's major release schedule is crazy.
Sometimes, merging without review is needed for LDC because of manpower (sometimes also review is not taken well, resulting in bad feelings). But we do have to keep up and improve testing and be even more wary of ones own changes. Aside: having 3 of our Travis jobs as "allow failure" is very unfortunate. :(
I think we can just politely ignore such complaints as long as we are not years behind DMD. There will always be a delay, and probably those folks are just hard to satisfy anyway (I find such comments quite disrespectful of our time and work). There's also a group of people who want a stable language that we also shouldn't alienate. |
Heh, my brain apparently used to replace the last digit with LDC's minor version ( |
Sounds good, I hope it plays out.
I know (and try to be); new tests in newer frontends (and defaultlib unittests) make me feel more and more comfortable with overall quality.
I actually hoped a user would hit it too and so lead to more information about it. It's more looking like a Travis strangeness now, as the single failing DMD test worked fine on both other Ubuntu 14.04 CI platforms (and in my then-16.04 VM). IIRC, Travis and SSH isn't straightforward (so that I chose Circle for that), so I went ahead and allowed the 2 BUILD_SHARED_LIBS=ON jobs to fail as quick remedy; removing the test file probably makes more sense now (as done for other CI strangeness too). |
|
@redstar, any input? |
|
Should we go ahead with this? I think we've given every one time to weigh in. |
|
Would be good to get this in before the second beta, so people know we're making this move. Now is a good time to make the shift, because going to 1.10 may cause similar version numbering problems for build scripts, so might as well make the bigger jump to 2.080, rather than doing it twice. @JohanEngelen, please merge if you're okay with this, I don't see a reason not to. |
|
I'm not sure changing the scheme now inbetween betas is a good idea; that's why I wanted the decision before publishing beta1.
Anything particular in mind? Two-digit minor versions wouldn't be something new (0.17). |
|
I doubt between the betas matters, most will only probably package the final release. As for numbering issues, packaging systems do all kinds of weird things, like thinking 1.10 is lower than 1.9, or the famous issue where Windows went from 8 to 10 supposedly because they were worried about software only checking the first digit and confusing 9 with 95. Of course, these numbering issues may not really crop up that much for us, just a possibility. But we're going to hit this potential problem here after 1.9 regardless, I think we might as well make the bigger jump once. |
|
We already packaged the beta. Any such issues would occur just the same with DMD-style version numbers, so nothing to be gained here from rushing things. Besides, large minor versions are awfully common in open source software (0.22, MediaWiki 1.30, …), so package managers can handle that just fine. I'd still like to see a proper discussion of the proposed version switch – including packagers – and announcement on the forums before thinking of implementing something like that. There is little to be gained by switching, but the potential for considerable confusion. |
We already released a manual download, which presents no issues for version numbering, I'm talking about downstream packagers.
Not once we switched to DMD version numbering because of its leading zero, the only potential problem would be from this initial jump.
That's true, which is why I said it's a possible problem, not guaranteed.
If a forum discussion is so necessary, wish you'd mentioned it a month ago when you first chimed in, but it may be worth doing, so done.
On the contrary, I think this move would remove confusion that has been there for years about which ldc version corresponds to a dmd version. |
|
As long as the version number increases and you are certain that you will not jump back to a lower version at some point, changing the version is fine for a Linux distributor. However, I am a bit concerned over the version jumps being a bit confusing for users, and LDC-specific changes now being in the patch part of the version (in general, it feels like a pretty confusing change). |
|
Also note that DMD itself is considering a change in version numbering scheme. |
To what? Would make sense to match that. |
https://forum.dlang.org/post/drcekmxvfszpwifbukzk@forum.dlang.org (no clear consensus has been found though). |
|
Time to push this through? |
|
Well, people seem not to really care, at least that's the picture I get, so IMO we can wait and see if the DMD versioning discussion is going anywhere. |
|
People don't really care about what? Certainly, no issues with matching dmd's versioning have materialized. As for the upstream versioning changing, that was proposed 8 months ago to be changed earlier this year, and nothing has happened, with no updates to that thread for a couple months. Unless one of you has inside info on an imminent dmd versioning change, I don't think they will change their versioning anytime soon. If you mean users on the forum or github haven't called for this versioning change, that's the point: this kind of change is not made for them. It's made for the majority of users who will never read the forum or github in the first place, to make it easy for them to know what D version they're using when they use ldc. |
|
Alright, can we finally get this in? |
|
Ping, if you update this to latest, we can get this in before the next beta. |
|
I still think we should do this, but if you're not going to, just close the pull. |
No description provided.