lostluck commented on code in PR #17766:
URL: https://github.com/apache/beam/pull/17766#discussion_r882958477


##########
website/www/site/content/en/documentation/sdks/go-dependencies.md:
##########
@@ -0,0 +1,37 @@
+---
+type: languages
+title: "Go SDK Dependencies"
+---
+<!--
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+# Beam SDK for Go dependencies
+
+The Beam SDKs depend on common third-party components which then
+import additional dependencies. Version collisions can result in unexpected
+behavior in the service. If you are using any of these packages in your code, 
be
+aware that some libraries are not forward-compatible and you may need to pin to
+the listed versions that will be in scope during execution.

Review Comment:
   This isn't the standard in Go BTW, and the Diamond Dependency problem isn't 
as much of a problem. Essentially two different major versions of a package are 
two different packages as far as the compiler is concerned.
   
   Healthy packages have a major version release to indicate breaking changes 
the external APIs. And to use a new major version, the imports would need to 
change as well. 
   Otherwise the two distinct major versions of the same can happily live in 
the same binary.
   
   See https://go.dev/doc/modules/release-workflow#breaking and 
https://go.dev/blog/module-compatibility
   
   Granted, that's the ideal, but in cases where that's not the case:
   https://go.dev/ref/mod#go-mod-file-exclude
   
   
   All this is largely to say, for folks concerned with Go Dependencies, we 
should communicate to them in Go terms. Emphasize that the Beam Go SDK is using 
Go Modules, and that the Go documentation on the topic applies, and most 
importantly: not repeat more than we have to.  
   
   The section specifics below are fine though, incase a non-go users wanders 
onto the page



-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to