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>

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!

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

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.

On 5/20/18 8:07 AM, Sönke Ludwig wrote:

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

Isn't diet-ng used by 0.7.x branch now? It seems to be selected when I'm using 0.7.x

-Steve

Am 21.05.2018 um 17:34 schrieb Steven Schveighoffer:
> On 5/20/18 8:07 AM, Sönke Ludwig wrote:
> 
>> 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.
> 
> Isn't diet-ng used by 0.7.x branch now? It seems to be selected when I'm using 0.7.x
> 
> -Steve

You are right, I misremembered that! The difference is just that in 0.8.0 it is now mandatory, and the old implementation got dropped.