proposal for fragment spec

[catagits/Catalyst-Runtime.git] / lib / Catalyst / Delta.pod

diff --git a/lib/Catalyst/Delta.pod b/lib/Catalyst/Delta.pod
index 1366f09..e75a052 100755 (executable)
--- a/lib/Catalyst/Delta.pod
+++ b/lib/Catalyst/Delta.pod
@@ -7,6 +7,35 @@ Catalyst::Delta - Overview of changes between versions of Catalyst
 This is an overview of the user-visible changes to Catalyst between major
 Catalyst releases.
 
+=head2 VERSION 5.90097
+
+=head3 Defined how $c->uri_for adds a URI fragment.
+
+We now have a specification for creating URIs with fragments (or HTML anchors).
+Previously you could do this as a side effect of how we create URIs but this
+side effect behavior was never documented or tested, and was broken when we
+introduced default UTF-8 encoding.  When creating URIs with fragments please
+follow the new, supported specification:
+
+    $c->uri_for($action_or_path, \@captures_or_args, @args, \$query, \$fragment);
+
+This will be a breaking change for some codebases, we recommend testing if
+you are creating URLs with fragments.
+
+=head2 VERSION 5.90094
+
+=head3 Multipart form POST with character set headers
+
+When we did the UTF8 work, we punted on Form POSTs when the POST envelope was
+multipart and each part had complex headers such as content-types, character
+sets and so forth.  In those cases instead of returning a possibly incorrect
+value, we returned an object describing the part so that you could figure it
+out manually.  This turned out to be a bad workaround as people did not expect
+to find that object.  So we changed this to try much harder to get a correct
+value.  We still return an object if we fail but we try much harder now.  If
+you used to check for the object you might find that code is no longer needed
+(although checking for it should not hurt or break anything either).
+
 =head2 VERSION 5.90091
 
 =head3 'case_sensitive' configuration