Am 18.05.2018 um 16:00 schrieb Seb:
On Friday, 18 May 2018 at 13:46:45 UTC, Márcio Martins wrote:
On Wednesday, 16 May 2018 at 08:48:15 UTC, Sönke Ludwig wrote:
Being the final public release on the 0.7.x branch, this version on
DMD 2.068.2 up to DMD 2.080.0 and LDC 1.9.0. It includes some major
fixes and improvements backported from the 0.8.x branch. Since this
marks the last 0.7.x release, all code depending on it should now be
upgraded to 0.8.3 or later.
Change log:
<http://vibed.org/blog/posts/vibe-release-0.7.33>
DUB package:
<https://code.dlang.org/packages/vibe-d/0.7.32>
Comparing with 0.7.x, how production-ready would you say the 0.8.x
branch is, and what are the main advantages?
Thank you for the awesome work!
I think I can try to answer this for you.
0.8.x has been in production use for almost a year now.
There have been tons of improvements in the API, performance and new
functionality, so it's hard to boil down individual items. The full
changelog is here:
http://vibed.org/blog/posts/vibe-release-0.8.0
The biggest change is probably that 0.8 now uses subpackages and the new
vibe-core package is available for opt-in usage.
Vibe-core is a pure D replacement of the old libevent-based
event-handling (that's simplified because the actual logic is done by
eventcore and it contains more functionality too).
Anyhow, there have been a few regressions when vibe.d switched to use
the new vibe-core in 0.8.3, but funnily it also fixed quite a few
existing issues with libevent.
So tl;dr: it's safe to upgrade and if you run into any immediate
troubles, stick to the old libevent for one or two releases (it can be
selected via the vibe-core subconfiguration).
To add to this, when using the libevent driver, the major changes are
mainly just type system related (`@safe` and `nothrow` support), so in
terms of functionality and risk of regressions it is probably safe to
say that it is not much different than a 0.7.x point release.
The new vibe-core module also runs fine in most contexts, but seems to
amplify a GC memory consumption/leak issue (visible in the DUB registry)
and there is still an unresolved report of performance issues in the
HTTP client (which I couldn't reproduce so far). So this should still be
used with care in production - on the other hand, any controlled
real-world exposure is of course highly desirable in order to pinpoint
any remaining issues.
As Sebastian pointed out, it does fix quite a number of existing, but
rarely encountered, issues that exist in the libevent implementation,
because it uses a much more robust approach to fiber scheduling. It also
has the potential for much better performance, although that is
currently still nullified by some implementation choices in the HTTP
server code.
Another big improvement is the diet-ng library, which uses less
compile-time memory and is a lot more flexible than the old
`vibe.textfilter.diet` module.