rob05c commented on a change in pull request #5345:
URL: https://github.com/apache/trafficcontrol/pull/5345#discussion_r541124937
##########
File path: lib/go-tc/deliveryservices.go
##########
@@ -179,6 +188,11 @@ type DeliveryServiceNullableV30 struct {
ServiceCategory *string `json:"serviceCategory"
db:"service_category"`
}
+type DeliveryServiceV31 struct {
+ DeliveryServiceNullableV30
+ MaxRequestHeaderSize *int `json:"maxRequestHeaderSize"
db:"max_request_header_size"`
+}
+
// Deprecated: Use versioned structures only from now on.
type DeliveryServiceNullable DeliveryServiceNullableV15
Review comment:
FWIW, I ended up making an alias in `lib/go-atscfg` for both the latest
DS and Server. Just for stability, because it kept changing, and requiring
updating hundreds of lines of code. Where using the alias lets me just update
that single location, and the few places that broke.
I don't currently have a strong opinion on this. But I think we should do
whatever is easy for users to work with. From my recent experience, that seems
to be an alias.
> That should work out fine, since the only kinds of changes that should
break alias property access are the same kinds that would necessitate a major
version bump.
Right, that's the big issue: how does an updating alias work with Go Modules
and the library Version Promise?
It's a little bit nebulous what constitutes "breaking." The updating minor
alias will only break if people use the nested initialization, e.g. `sv :=
tc.Server{tc.ServerV3{tc.ServerV2{Foo: foo}, Bar: bar}}` vs `sv := tc.Server{};
sv.Foo = foo; sv.Bar = bar`.
I think I'd be ok with declaring that unsupported in terms of the Go Modules
and the library compatibility promise, and documenting so a symbol comment.
"Struct alias initialization is only guaranteed forward-compatible for
default-initialization" (maybe with an example).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
