Update to Go 1.23 #345

New issue

Open

opened 2025-03-07 11:49:27 +00:00 by fyrchik · 3 comments

fyrchik commented

2025-03-07 11:49:27 +00:00

Owner

https://go.dev/blog/range-functions
Iterate..() functions like this one

// IterateAttributes iterates over all node attributes and passes the into f.

, should use custom iterators.
Unnecessary clones could be removed too

func (o *Object) Attributes() []Attribute {

https://go.dev/blog/range-functions `Iterate..()` functions like this one https://git.frostfs.info/TrueCloudLab/frostfs-sdk-go/src/commit/69b0711d12d94cf4cb07eb1de218c1955a3c66ad/netmap/node_info.go#L396 , should use custom iterators. Unnecessary clones could be removed too https://git.frostfs.info/TrueCloudLab/frostfs-sdk-go/src/commit/f70c0c9081a996e34121debaff56ed98b72eafcd/object/object.go#L304 .

fyrchik added the

label 2025-03-07 11:49:27 +00:00

fyrchik commented

2025-03-07 11:53:29 +00:00

Author

Owner

For attributes lets also discuss iteration that maps attribute.Key and attribute.Value to native keys and values.
Like

for k, v := range o.AttributesSeq() {
  fmt.Printf("Key: %s, Value: %s\n", k, v)
}

For attributes lets also discuss iteration that maps `attribute.Key` and `attribute.Value` to native keys and values. Like ```go for k, v := range o.AttributesSeq() { fmt.Printf("Key: %s, Value: %s\n", k, v) } ```

fyrchik added the

discussion

label 2025-03-07 11:53:58 +00:00

potyarkin commented

2025-03-07 12:02:35 +00:00

Member

As SDK maintainers what's our process to decide when it's OK to drop support of older Go versions?

Even though upgrading Go toolchain is not as big of a deal as with some other languages it's not that difficult to imagine some app developers choosing to stay a few versions behind for various reasons. It would be beneficial to provide some transparency on this topic.

As SDK maintainers what's our process to decide when it's OK to drop support of older Go versions? Even though upgrading Go toolchain is not as big of a deal as with some other languages it's not that difficult to imagine some app developers choosing to stay a few versions behind for various reasons. It would be beneficial to provide some transparency on this topic.

fyrchik commented

2025-03-10 06:57:17 +00:00

Author

Owner

As SDK maintainers what's our process to decide when it's OK to drop support of older Go versions?

We support the last 2 Go versions, so when a new one come out (usually in february or august https://go.dev/wiki/Go-Release-Cycle), we drop the old one. I believe, Go itself supports the current and the previous release. neo-go (our dependency) does so too https://github.com/nspcc-dev/.github/blob/master/go.md

Transparency is good too, let's mention this in README.md as a part of this task.

>As SDK maintainers what's our process to decide when it's OK to drop support of older Go versions? We support the last 2 Go versions, so when a new one come out (usually in february or august https://go.dev/wiki/Go-Release-Cycle), we drop the old one. I believe, Go itself supports the current and the previous release. neo-go (our dependency) does so too https://github.com/nspcc-dev/.github/blob/master/go.md Transparency is good too, let's mention this in README.md as a part of this task.

👍 1