About Libraries Versioning

[Eyal]

Hi

The recommended way to create a new version for a go library is by copying the library code to a v2 directory. I am against this approach from the following reasons:

1. Code duplication: harder to back port fixes, harder to follow, not "nice".
2. Commits history contains history of all versions, which is messy.
3. Project root is still the oldest version.
4. Feels like a workaround.

There is another option - much more elegant, also mentioned in the cited blog post - to use branches as versions. In this way there is no code duplication, fix commits can be usually cherry-picked to older versions, commit tree reflects only the current version history and the main view and project root are the latest version. The down side of this approach, as mentioned in the blog post, is that "tools that are not version-aware — including the go command in GOPATH mode — may not distinguish between major versions".

My opinion is that the recommended solution is kind of a workaround. Is it the solution for the long run? Will go modules start having "v*" sub directories with code duplication? It feels like a wrong direction to the community to me.

I would appreciate if you have any solutions or opinions about it.

Thanks!

Eyal

[Jan Mercl]

On Wed, Nov 20, 2019 at 2:42 PM Eyal <pos...@gmail.com> wrote:

> The recommended way to create a new version for a go library is by copying the library code to a v2 directory.

Only if the new version that breaks backward compatibility. Bug fixes
and/or new features do not need such switch.

[Eyal]

Of coarse, sorry for not mentioning it. I still think that this is a major issue.

[Eyal]

Summaries my conclusions on this journey: https://posener.github.io/branch-strategy/

Enjoy!