Summaries my conclusions on this journey: https://posener.github.io/branch-strategy/
Enjoy! On Wednesday, November 20, 2019 at 3:42:11 PM UTC+2, Eyal wrote: > > Hi > > The recommended way <https://blog.golang.org/v2-go-modules> 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/634dee63-079a-47e9-af38-c53bc2787490%40googlegroups.com.
