The major changes in this release are HTTP forward proxy support, handling incoming HTTP requests on custom transports and a MongoDB based session store. On top of that, there are many smaller improvements in the HTTP server, web/REST generator, JSON/BSON support and the TLS sub system.

Change log:
https://vibed.org/blog/posts/vibe-release-0.8.2

DUB package:
https://code.dlang.org/packages/vibe-d/0.8.2

that's great... unfortunately https://github.com/vibe-d/vibe.d/issues/1991 is a regression preventing from updating to 0.8.X (has a reduced test case). Any help on this would be very appreciated, thanks!

On Tue, Dec 12, 2017 at 11:44 AM, Sönke Ludwig via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> The major changes in this release are HTTP forward proxy support, handling incoming HTTP requests on custom transports and a MongoDB based session store. On top of that, there are many smaller improvements in the HTTP server, web/REST generator, JSON/BSON support and the TLS sub system.
>
> Change log:
> https://vibed.org/blog/posts/vibe-release-0.8.2
>
> DUB package:
> https://code.dlang.org/packages/vibe-d/0.8.2

On Tuesday, 12 December 2017 at 19:44:17 UTC, Sönke Ludwig wrote:
> The major changes in this release are HTTP forward proxy support, handling incoming HTTP requests on custom transports and a MongoDB based session store. On top of that, there are many smaller improvements in the HTTP server, web/REST generator, JSON/BSON support and the TLS sub system.
>
> Change log:
> https://vibed.org/blog/posts/vibe-release-0.8.2
>
> DUB package:
> https://code.dlang.org/packages/vibe-d/0.8.2

I think you should mention more prominently that for people who want to use OpenSSL 1.1, they can now use:

dub --override-config="vibe-d:tls/openssl-1.1"


This allows to use OpenSSL 1.1 _without_ needing to set the `VibeUseOpenSSL11` version in their dub.sdl

On Tuesday, 12 December 2017 at 19:44:17 UTC, Sönke Ludwig wrote:
> The major changes in this release are HTTP forward proxy support, handling incoming HTTP requests on custom transports and a MongoDB based session store. On top of that, there are many smaller improvements in the HTTP server, web/REST generator, JSON/BSON support and the TLS sub system.
>
> Change log:
> https://vibed.org/blog/posts/vibe-release-0.8.2
>
> DUB package:
> https://code.dlang.org/packages/vibe-d/0.8.2

Great job

Am 13.12.2017 um 01:24 schrieb Seb:
> I think you should mention more prominently that for people who want to use OpenSSL 1.1, they can now use:
> 
> dub --override-config="vibe-d:tls/openssl-1.1"
> 
> 
> This allows to use OpenSSL 1.1 _without_ needing to set the `VibeUseOpenSSL11` version in their dub.sdl

Thanks for the pointer, I completely forgot about that. It's now mentioned in the release announcement, as well as in the README and in the TLS section of the documentation:

https://vibed.org/blog/posts/vibe-release-0.8.2

Am 13.12.2017 um 00:49 schrieb Timothee Cour:
> that's great... unfortunately
> https://github.com/vibe-d/vibe.d/issues/1991 is a regression
> preventing from updating to 0.8.X (has a reduced test case). Any help
> on this would be very appreciated, thanks!

I'll have a look at this. Unfortunately serialization and @safe do not go well together due to https://issues.dlang.org/show_bug.cgi?id=16528 so that currently manual (non-generic) workarounds are required, and there may be other similar issues lurking.

For the specific code, if possible, the easiest way to sidestep the error would be to use @safe or @trusted on those property functions.

This shouldn't have been released as 0.8.2, because it has a lot of breaking changes.

For an instance anything that relies on HTTPServerRequest.path will break.

I'm aware that there has been added the "requestPath" property, but it's still a breaking change to all existing code that relies on the old "path" property. Especially when it's used to manipulate the path you receive.

Diamond cannot currently be used with latest release of vibe.d, because of this and it was relying on vibe.d with following dependency:

"vibe-d": "~>0.8.1"

0.8.2 should not be a breaking change, assuming you follow semantic versioning.

https://semver.org/

On Sunday, 17 December 2017 at 12:52:57 UTC, bauss wrote:
> This shouldn't have been released as 0.8.2, because it has a lot of breaking changes.
>
> For an instance anything that relies on HTTPServerRequest.path will break.
>
> I'm aware that there has been added the "requestPath" property, but it's still a breaking change to all existing code that relies on the old "path" property. Especially when it's used to manipulate the path you receive.
>
> Diamond cannot currently be used with latest release of vibe.d, because of this and it was relying on vibe.d with following dependency:
>
> "vibe-d": "~>0.8.1"
>
> 0.8.2 should not be a breaking change, assuming you follow semantic versioning.
>
> https://semver.org/

4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

On Sunday, 17 December 2017 at 14:13:05 UTC, WebFreak001 wrote:
> On Sunday, 17 December 2017 at 12:52:57 UTC, bauss wrote:
>> This shouldn't have been released as 0.8.2, because it has a lot of breaking changes.
>>
>> For an instance anything that relies on HTTPServerRequest.path will break.
>>
>> I'm aware that there has been added the "requestPath" property, but it's still a breaking change to all existing code that relies on the old "path" property. Especially when it's used to manipulate the path you receive.
>>
>> Diamond cannot currently be used with latest release of vibe.d, because of this and it was relying on vibe.d with following dependency:
>>
>> "vibe-d": "~>0.8.1"
>>
>> 0.8.2 should not be a breaking change, assuming you follow semantic versioning.
>>
>> https://semver.org/
>
> 4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

0.x.Y should always be compatible with 0.x.Z without breaking changes.

Since it's MAJOR.MINOR.PATCH

This is a patch release 0.8.1 to 0.8.2 which means:

"PATCH version when you make backwards-compatible bug fixes."

Even a minor version should be backward-compatible.

"MINOR version when you add functionality in a backwards-compatible manner, and"

I'm all for deprecating said features, but plain removing them in a release like this is a breaking change and should at the very least be a minor version upgrade, but definitely not a patch.

Am 17.12.2017 um 16:24 schrieb bauss:
> On Sunday, 17 December 2017 at 14:13:05 UTC, WebFreak001 wrote:
>> On Sunday, 17 December 2017 at 12:52:57 UTC, bauss wrote:
>>> This shouldn't have been released as 0.8.2, because it has a lot of breaking changes.
>>>
>>> For an instance anything that relies on HTTPServerRequest.path will break.
>>>
>>> I'm aware that there has been added the "requestPath" property, but it's still a breaking change to all existing code that relies on the old "path" property. Especially when it's used to manipulate the path you receive.
>>>
>>> Diamond cannot currently be used with latest release of vibe.d, because of this and it was relying on vibe.d with following dependency:
>>>
>>> "vibe-d": "~>0.8.1"
>>>
>>> 0.8.2 should not be a breaking change, assuming you follow semantic versioning.
>>>
>>> https://semver.org/
>>
>> 4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
> 
> 0.x.Y should always be compatible with 0.x.Z without breaking changes.
> 
> Since it's MAJOR.MINOR.PATCH
> 
> This is a patch release 0.8.1 to 0.8.2 which means:
> 
> "PATCH version when you make backwards-compatible bug fixes."
> 
> Even a minor version should be backward-compatible.
> 
> "MINOR version when you add functionality in a backwards-compatible manner, and"
> 
> I'm all for deprecating said features, but plain removing them in a release like this is a breaking change and should at the very least be a minor version upgrade, but definitely not a patch.

The above was actually a quote from the spec, so there is no doubt that any 0.x.y release may contain breaking changes. But apart from that, the development has always gone this way so far. I just made 0.8.0 a new "minor" version, because it is in many ways a much larger step than the previous releases and not all breaking changes could reasonably follow the usual deprecation paths.

However, as individual sub packages are separated out into their own repositories (such as diet-ng and vibe-core), their versioning will start as 1.0.0 and will follow the usual versioning rules for >= 1.x.y releases.

But what do you mean with anything will break using `.path`? It follows the usual deprecation path - currently it's just documented as deprecated. In one or two releases, the `deprecated` attribute will be set and a few releases later it will finally be removed. By that time projects will have had quite some time to react on the deprecation.