www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Released vibe.d 0.8.2

reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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
Dec 12 2017
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
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
Dec 12 2017
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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.
Dec 13 2017
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
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
Dec 12 2017
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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
Dec 13 2017
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
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
Dec 12 2017
prev sibling parent reply bauss <jj_1337 live.dk> writes:
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/
Dec 17 2017
parent reply WebFreak001 <d.forum webfreak.org> writes:
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.
Dec 17 2017
parent reply bauss <jj_1337 live.dk> writes:
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.
Dec 17 2017
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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.
Dec 17 2017
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 17 December 2017 at 19:13:44 UTC, Sönke Ludwig wrote:

 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.


HTTPServerRequest.path does not have the same definition as 
previously.

It has been changed from a field to a getter function.

Tbh. it should just have been marked with deprecated instead of 
being removed, as you do specify is the normal deprecation 
process.

0.8.1:
		/** The _path part of the URL.

			Remarks: This field is only set if HTTPServerOption.parseURL 
is set.
		*/
		string path;

0.8.2:
		/** Deprecated: The _path part of the URL.

			Note that this function contains the decoded version of the
			requested path, which can yield incorrect results if the path
			contains URL encoded path separators. Use `requestPath` 
instead to
			get an encoding-aware representation.
		*/
		string path()  safe {
			if (_path.isNull) {
				_path = urlDecode(requestPath.toString);
			}
			return _path.get;
		}

		private Nullable!string _path;

There should still have been a setter property like:

void path(string newPath);

Which should be marked with deprecated until it could be safely 
removed.
Dec 17 2017
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 17 December 2017 at 20:55:15 UTC, bauss wrote:

 		private Nullable!string _path;


Also does this really make sense?

Why not just have it:

private string _path;

Then instead of:
		string path()  safe {
			if (_path.isNull) {
				_path = urlDecode(requestPath.toString);
			}
			return _path.get;
		}

You could have:
		string path()  safe {
			if (!_path) {
				_path = urlDecode(requestPath.toString);
			}
			return _path;
		}
Dec 17 2017
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 17.12.2017 um 21:56 schrieb bauss:

 On Sunday, 17 December 2017 at 20:55:15 UTC, bauss wrote:

         private Nullable!string _path;


 
 Also does this really make sense?
 
 Why not just have it:
 
 private string _path;
 
 Then instead of:
          string path()  safe {
              if (_path.isNull) {
                  _path = urlDecode(requestPath.toString);
              }
              return _path.get;
          }
 
 You could have:
          string path()  safe {
              if (!_path) {
                  _path = urlDecode(requestPath.toString);
              }
              return _path;
          }


That would certainly be possible. Using a `Nullable` is mainly just more 
explicit.
Dec 17 2017
prev sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 17.12.2017 um 21:55 schrieb bauss:

 On Sunday, 17 December 2017 at 19:13:44 UTC, Sönke Ludwig wrote:

 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.


 
 HTTPServerRequest.path does not have the same definition as previously.
 
 It has been changed from a field to a getter function.


True, this can be a breaking change, but setting this field looks like 
something that is outside of any sane use case. The field should ideally 
have been const/immutable before.


 
 Tbh. it should just have been marked with deprecated instead of being 
 removed, as you do specify is the normal deprecation process.


What do you mean with this? Keeping the field with a `deprecated` 
attribute, and at the same time add the getter property?


 
 0.8.1:
          /** The _path part of the URL.
 
              Remarks: This field is only set if 
 HTTPServerOption.parseURL is set.
          */
          string path;
 
 0.8.2:
          /** Deprecated: The _path part of the URL.
 
              Note that this function contains the decoded version
of the
              requested path, which can yield incorrect results if
the path
              contains URL encoded path separators. Use
`requestPath` 
 instead to
              get an encoding-aware representation.
          */
          string path()  safe {
              if (_path.isNull) {
                  _path = urlDecode(requestPath.toString);
              }
              return _path.get;
          }
 
          private Nullable!string _path;
 
 There should still have been a setter property like:
 
 void path(string newPath);
 
 Which should be marked with deprecated until it could be safely removed.
Dec 17 2017