Release 1.6.0

[oleg-jukovec]

Overview

This release adds a number of features. Also it significantly improves testing, CI and documentation.

Breaking changes

There are no breaking changes in the release.

New features

• Support UUID type in msgpack (Is there support of built-in UUID type? #90).
• queue-utube handling (Add utube handling (without unrelated changes) #85).
• Master discovery (Automatic master discovery #113).
• SQL support (Could I use SQL syntax to query to Tarantool? #62).

Bugfixes

• Reset buffer if its average use size smaller than quater of capacity ((*smallWBuf).Write holds memory #95).

Testing

• Coveralls support (Support code coverage #149).
• Reusable testing workflow (integration testing with latest Tarantool) (github-ci: add reusable testing workflow #112).
• Simple CI based on GitHub actions (Set up simple CI based on GitHub Actions #114).
• Handle everything with go test (Queue tests fail #115).
• Fix queue tests (Make test run self-sufficing #107).
• Make test case consistent with comments (Test fails with Tarantool 2.8.1 or newer #105).

Other

• Go modules support (Add go modules support #91).
• Update API documentation: comments and examples (Consider generation of API documentation from sources #123).

[oleg-jukovec]

From the wiki page:

Rename 'Unreleased' version to the next version number with release date and add a new empty section 'Unreleased' with empty Added, Changed, Removed subsections.

But I left empty Added, Changed, Fixed subsections. Because it was in the CHANGELOG.md before and it is now at crud. Should I change the CHANGELOG.md or the wiki page?

[oleg-jukovec]

I made a draft release too.

[Totktonada]

I usually add build/testing/CI/code health changes into its own section(s) (example), because it is mostly for developers. I look at the release notes mainly in reflection of the 'what is new from a user point of view' -- this information should be presented at beginning of the document. But we can add 'what else nice occurs here' at bottom.

[Totktonada]

Should I change the CHANGELOG.md or the wiki page?

I agree. Let's modify the instruction of the wiki.

[Totktonada]

Regarding CHANGELOG.md vs release notes format. I'm not a fan of keepachangelog.com format. I would write changelogs in a convenient format and form release notes by copying the changelog (plus, maybe, some overview section). However we state that we adhere keepachangelog.com in CHANGELOG.md, so we can't. I propose to extract developer information into its own section in release notes, but keep the CHANGELOG.md format as is for now. Later we can revisit it.

[oleg-jukovec]

I usually add build/testing/CI/code health changes into its own section(s) (example)

Thank you, I like it. I've added Testing and Other sections into the commit message, into the pull request message and into the draft release request. I will synchronize the wiki page with the changes after the release.

[DifferentialOrange]

Reusable testing workflow (integration testing with latest Tarantool) (#123).

It looks like wrong issue is linked.

[DifferentialOrange]

LGTM after resolving a comment above.

How Golang modules are released? Is repo tag enough?

[oleg-jukovec]

Reusable testing workflow (integration testing with latest Tarantool) (#123).

It looks like wrong issue is linked.

Thank you. You are right. It's #112.
I've updated CHANGELOG.md, the commit message, the pull request message, the draft pull request.

[oleg-jukovec]

How Golang modules are released? Is repo tag enough?

https://go.dev/blog/publishing-go-modules

It's enough until v2.