Re: [go-nuts] About Libraries Versioning

[Eyal]

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

On Wednesday, November 20, 2019 at 3:47:25 PM UTC+2, Jan Mercl wrote:
>
> On Wed, Nov 20, 2019 at 2:42 PM Eyal > 
> 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. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d0b49ee2-e666-4cdb-b862-024a99c8d236%40googlegroups.com.

Re: [go-nuts] About Libraries Versioning

[Jan Mercl]

On Wed, Nov 20, 2019 at 2:42 PM Eyal  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.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-X2rgRfNEFS9yJ4cktCRmC_jG29ObNA54awZCZo5rhvgw%40mail.gmail.com.

[go-nuts] 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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c4b2f832-536c-469c-a1c3-2f2824e51d37%40googlegroups.com.