go: Add info how to work with the new Go version

README.md

@@ -4,3 +4,19 @@ This repository contains an organization-wide profile README as well as a set
 of policies describing how organization works and what it expects from its
 contributors. Generic workflows reused by multiple other repositories in the
 organization are also stored here.
+
+## Table of Contents
+
+- [Profile](profile/README.md) - Discover the NeoSPCC team, focused on the 
+  development of NeoFS and NeoGo, contributing significantly to advancements in
+  decentralized storage technologies and the Neo blockchain platform.
+- [Git](git.md) - Learn about requirements and techniques related to how we use
+  Git and manage repositories.
+- [Go](go.md) - Dive into the Go version updates with a guide.
+- [Labels](labels.md) - Understand how to use labels effectively in issue 
+  tracking to organize tasks, bugs, and features.
+- [Project Management](project-management.md) - Explore the essentials of 
+  organization project management, including versioning, milestones, 
+  assignments, PR discussions, issue closure, and documentation.
+- [Contributing](CONTRIBUTING.md) - We welcome contributions! Please take a 
+  look if you have suggestions, corrections, or documents to add. 

go.md

@@ -0,0 +1,28 @@
+# GO
+
+## Version updates
+
+Upon the release of a new version of Go, all repositories are updated
+according to the following conventions:
+* The minimum supported version of Go is set to two versions back from 
+  the previous one. For example, upon the release of Go 1.22, the minimum 
+  version becomes 1.20.
+* All dependency packages are updated (sometimes, according to project 
+  requirements, some deprecated package methods may be updated as well.)
+* New Go version features are adapted where they make sense or can improve 
+  performance.
+* Go versions in GitHub workflows are also updated as follows:
+
+  1. Testing is performed on the last three versions of Go. In the example
+  mentioned above, this would be `[ '1.20', '1.21', '1.22' ]`.
+  2. For build and cover jobs, the latest version should be used. In the 
+  example mentioned above, this would be 1.22. 
+  3. If there are new versions of GitHub actions, they can also be updated 
+  (for example, actions/checkout, actions/setup-go, actions/upload-artifact, 
+  etc.).
+  4. The Go version for the linter equals the minimum supported version and 
+  is usually taken from the `go.mod` file by specifying in the *.yml file:
+  ```        
+  with:
+    go-version-file: 'go.mod'
+  ```