Why is master version on 1.3.1

[ccojocar]

Hey there and thank you for opening an issue!

Please help us keep the number of opened issues under control.

Do the checklist before filing an issue:

• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
• Have a usage question? Ask in our slack channel (see https://goa.design to join).

None of the above, create a bug report:

Make sure to add all the information needed to understand the bug so that someone can help. If the info is missing we'll add the 'Needs more information' label and close the issue until there is enough information.

Please fill the sections below:

Expected Behavior

I expect that the master version to be on 1.4.0 since this was already released. Any particular reason for keep the master on 1.3.1 in the version file?

goa/version/version.go

Line 13 in e6e9ecb

Minor = 3

Actual Behavior

Steps to Reproduce the Problem (including complete and simple design if relevant)

Specifications

• goa Version:
• Platform (Linux/Windows etc.):

[klauspost]

Related: #1867

[raphael]

Yeah this is not a great state to be in. Things are getting even more complicated with the introduction of Go modules. The initial plan of making v2 the master branch does not work anymore since go get defaults to the v1 branch when using modules. I believe we'll have to introduce a new repository for v2 :( (because being able to use goa.design/goa as import path instead of github.com/goadesign/goa is something that's quite nice and would be good to keep). If that's the case then the question becomes what should the master branch become going forward? I believe we should reset master off of v1 and create an old-master branch for users that rely on it. Would love to hear your feedback on that plan @ccojocar @klauspost ...

[jtnord]

using go modules you can (and should) specify the tag /branch / sha you want so I do not see what impact this has with master being changed to be 1.4.0 and v2 work happening in a v2 branch?

[raphael]

The idea is to point goa.design/goa to v2 and github.com/goadesign/goa to v1. Today this works because goa.design/goa uses gopkg.in to redirect to v2. Go modules break this because go get does a local checkout of the v1 branch when getting goa.design/goa.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[raphael]

Thinking more about this, I think I agree with you @jtnord. Here is where we ended up after considering a number of alternatives and running these with members of the community, upon releasing v2:

• Leave the gopkg.in redirect in place so that importing goa.design/go with Go modules support disabled imports branch v2.
• Merge v2 into master and create a v2.0.0 release tag so that importing goa.design/goa with Go modules enabled works as long as the project that imports Goa uses v2.0.0 in its go.mod file.
• Release future versions by creating tags off of master.
• Merge master back into v2 when creating new releases - at least until we deprecate support for GOPATH.

Does that make sense to you @jtnord ?

[jtnord]

sounds reasonable to me.

[raphael]

Issue moved to #1959