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
itttttttttttt.
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.
