Release notes for 1.0 could make it more clear that "Fix URL generation (#592)" is a breaking change

[tanerkay]

The release notes for 1.0 mention "Fix URL generation (#592)".

I think it could help the upgrade journey for developers if it was made more clear that this is a significant change to how URLs are generated, rather than just a fix. This is because it now leverages the Laravel internals code which can return a different URL to the requestUri() used previously by this package.

Release notes at time of writing.

[RobertBoes]

The PR itself mentions what's changed, so I don't really see why that would need to be explained in the release notes? It's not really a breaking change that would require changes in user-land code.

[driesvints]

I'm not really sure I see a breaking change either.

[tanerkay]

@driesvints @RobertBoes

I specifically made this issue because it did cause a breaking change in an application's user-land code.

Example is if you use trailing slashes (for some reason, Laravel makes using them really hard).

Request URI: https://example.com/test/

$request->getBaseUrl().$request->getRequestUri(): /test/ (expected)
Str::start(Str::after($request->fullUrl(), $request->getSchemeAndHttpHost()), '/'): /test (trailing slash lopped off)

Not sure if there are other consequences. All I'm suggesting is editing the release notes to make this more obvious, instead of requiring a developer to dig deep into each individual PR and notice obscurities like this.

[driesvints]

I'm sorry @tanerkay but I don't think that's a valid use case. You should avoid using trailing slashes and redirect to urls without them. Here's a good article on how to do that: https://stefanbauer.me/tips-and-tricks/a-middleware-for-removing-trailing-slashes

[tanerkay]

@driesvints not my decision to make, I wish it was that simple.

anyway, up to you, it was just a suggestion to change "fix URL generation" to "change URL generation behaviour" in the release notes, didn't realise it would be so controversial