Re: Travis-CI support for D
Thanks for the great work! Is it possible to also include dmd+druntimie+phobos git-head? It would be helpful to know if your project can be built with the new version of DMD (when it is officially released) ahead of time. If you are using some yet-to be deprecated code you can fix the issue much sooner and when the next version is released the migration cost would be virtually zero. Sure, this won't be useful for everybody, but I am sure that for some larger organizations this will be helpful. Also this will help test the new compiler and standard library code better, which should benefit everyone. Git pulling and rebuilding dmd every time you update your project is not extremely efficient, but perhaps this can be done once a week. Or the autotester can upload the first binaries that pass all tests to some ftp in the beginning of every week. I am not very familiar with Travis or the dmd release process, so correct me if I am wrong.
Re: Travis-CI support for D
In the light of the DMD 2.066 regressions, I believe this would help bring the DMD release process closer to continuous delivery. https://www.youtube.com/watch?v=IBghnXBz3_w https://www.youtube.com/watch?v=igwFj8PPSnw
Re: Travis-CI support for D
On 12/13/2014 02:59 PM, ZombineDev wrote: Thanks for the great work! Is it possible to also include dmd+druntimie+phobos git-head? It would be helpful to know if your project can be built with the new version of DMD (when it is officially released) ahead of time. If you are using some yet-to be deprecated code you can fix the issue much sooner and when the next version is released the migration cost would be virtually zero. Sure, this won't be useful for everybody, but I am sure that for some larger organizations this will be helpful. Also this will help test the new compiler and standard library code better, which should benefit everyone. There are some interesting points in here, but the implication that more people should test master is wrong, at least I hope so. 1. New releases should be pain-free Obviously new releases shouldn't introduce regressions. If there are new warnings/deprecations you should be able to live with them for a while and fix them when you have time. This is how we perceive this and if that doesn't work for you I'd be interested to know why. 2. master == unstable There are quite some newsgroup posts like my project doesn't build with the latest dmd or latests dmd does A. That's not too helpful IMO, as it creates additional support overhead (deduplicating issues, answering, discussing). Therefor I wouldn't want to encourage this even more. If something breaks, go directly to bugzilla and file an issue. If you happen to know the cause go to github and add a comment on the relevant pull. New dmd and phobos code should be well tested and designed before we merge it into master. Things like std.experimental are supposed to deal with the lack of broad testing feedback during normal development. 3. Beta is for testing Alpha and beta releases are the right time to try a new release and they will be available on Travis-CI too [1]. During beta releases we're actively monitoring the dmd-beta mailing list [2] and are fixing any open regressions. This is the time when we're most receptive for newly reported issues. [1]: https://github.com/travis-ci/travis-build/pull/340/files#diff-ac986a81b67f1bd5851c535881c18abeR91 [2]: http://lists.puremagic.com/mailman/listinfo/dmd-beta Git pulling and rebuilding dmd every time you update your project is not extremely efficient, but perhaps this can be done once a week. Or the autotester can upload the first binaries that pass all tests to some ftp in the beginning of every week. I was thinking about releasing nightlies every now and then. We can't really reduce the release cycle without massively changing our workflow. That doesn't seem worthwhile for the few core contributors that we are. I am not very familiar with Travis or the dmd release process, so correct me if I am wrong. Done :) -Martin
Re: Travis-CI support for D
On 12/10/2014 08:50 PM, Martin Nowak wrote: Glad to announce that D support on Travis-CI was launched today. I'm a noob when it comes to travis, so it isn't readily apparent to me, but given this, would travis support a build that installs a d compiler and also some version of python?
Re: Travis-CI support for D
I agree with most of your points. I don't think that anyone should consider master (git head) as even remotely stable. It's about testing experimental features in early stages of development. That said, I still think that more testing can't do any harm. Additionally, having pre-alpha releases (including installers and so on) available on a regular basis, should improve the release process.
Re: Travis-CI support for D
Many successful software projects provide a way to get early, unstable versions if one desires to do so. For example Firefox has 4 channels with corresponding levels of stability: https://hacks.mozilla.org/2012/05/firefox-and-the-release-channels/
Re: Travis-CI support for D
On 14/12/2014 4:28 a.m., Martin Nowak wrote: On 12/13/2014 02:59 PM, ZombineDev wrote: Thanks for the great work! Is it possible to also include dmd+druntimie+phobos git-head? It would be helpful to know if your project can be built with the new version of DMD (when it is officially released) ahead of time. If you are using some yet-to be deprecated code you can fix the issue much sooner and when the next version is released the migration cost would be virtually zero. Sure, this won't be useful for everybody, but I am sure that for some larger organizations this will be helpful. Also this will help test the new compiler and standard library code better, which should benefit everyone. There are some interesting points in here, but the implication that more people should test master is wrong, at least I hope so. 1. New releases should be pain-free Obviously new releases shouldn't introduce regressions. If there are new warnings/deprecations you should be able to live with them for a while and fix them when you have time. This is how we perceive this and if that doesn't work for you I'd be interested to know why. 2. master == unstable There are quite some newsgroup posts like my project doesn't build with the latest dmd or latests dmd does A. That's not too helpful IMO, as it creates additional support overhead (deduplicating issues, answering, discussing). Therefor I wouldn't want to encourage this even more. If something breaks, go directly to bugzilla and file an issue. If you happen to know the cause go to github and add a comment on the relevant pull. New dmd and phobos code should be well tested and designed before we merge it into master. Things like std.experimental are supposed to deal with the lack of broad testing feedback during normal development. 3. Beta is for testing Alpha and beta releases are the right time to try a new release and they will be available on Travis-CI too [1]. During beta releases we're actively monitoring the dmd-beta mailing list [2] and are fixing any open regressions. This is the time when we're most receptive for newly reported issues. [1]: https://github.com/travis-ci/travis-build/pull/340/files#diff-ac986a81b67f1bd5851c535881c18abeR91 [2]: http://lists.puremagic.com/mailman/listinfo/dmd-beta Git pulling and rebuilding dmd every time you update your project is not extremely efficient, but perhaps this can be done once a week. Or the autotester can upload the first binaries that pass all tests to some ftp in the beginning of every week. I was thinking about releasing nightlies every now and then. We can't really reduce the release cycle without massively changing our workflow. That doesn't seem worthwhile for the few core contributors that we are. I am not very familiar with Travis or the dmd release process, so correct me if I am wrong. Done :) -Martin I'm also on the side of, we should get dmd, gdc and ldc nightlies available. As an early warning of issues instead of OMG it breaks fixxx i. Even though I don't use travis, I do think it would be a good thing to have. And anyway, it forces us to have good infrastructure going for automated releases.
Re: Travis-CI support for D
On Saturday, 13 December 2014 at 23:16:24 UTC, ZombineDev wrote: Many successful software projects provide a way to get early, unstable versions if one desires to do so. For example Firefox has 4 channels with corresponding levels of stability: https://hacks.mozilla.org/2012/05/firefox-and-the-release-channels/ Sorry, I missed that part of your reply: On Saturday, 13 December 2014 at 15:28:51 UTC, Martin Nowak wrote: I was thinking about releasing nightlies every now and then. We can't really reduce the release cycle without massively changing our workflow. That doesn't seem worthwhile for the few core contributors that we are.
Sargon component library now on Dub
http://code.dlang.org/packages/sargon These two modules failed to generate much interest in incorporating them into Phobos, but I'm still rather proud of them :-) Here they are: ◦sargon.lz77 - algorithms to compress and expand with LZ77 compression algorithm ◦sargon.halffloat - IEEE 754 half-precision binary floating point format binary16 I'll be adding more in the future.
