dep entry for goa client repo

[nurali-techie]

For f8-auth we have f8-auth-client repo which contains auto generated goa_client. Similar pair for wit and others.

Problem:
If f8-common wants to use f8-client-auth then dep entry would be:

[[constraint]]
  name = "github.com/fabric8-services/fabric8-auth-client"
  branch = "master"

Here, using master branch is problematic in case there will be incompatible changes in f8-auth goa_design.

The other option would be use revision with commit_sha but this is not good option as f8-common has to frequently keep changing dep entry.

Incompatible Change:
TODO: Please give an example of incompatible change in goa_design.

See: discussion here

Solution1:
As describe here but instead of releasing version, we can go with branch.

For ex,
T1 - f8-auth has some goa_design and ci build runs and calls generate_client_setup() with v1 and that will create v1 branch in f8-auth-client. Each time the content of v1 branch will be override with one_commit similar to how gh-pages branch maintained by github for docs_usecase.
T2 - f8-common has dep_entry with branch=v1
T3 - f8-auth did some goa_design with incompatible changes so need to pass v2 to generate_client_setup() and v2 branch will be created.

Pros:

• f8-common will not fail due to incompatible changes in f8-auth goa_design.
• f8-common no need to change dep entry frequently (unless there is incompatible change and f8-common want to adapt to it)
• f8-auth-client will be having less branch (one per incompatible change) and all these branch are useful.

Open Points:

• Is goa provide some way of api_versioning?? If so, that can be used to derive branch name for sol_1.

[alexeykazakov]

Btw I think a better way to track breaking changes in API would be contract testing.

[nurali-techie]

@alexeykazakov plz explain your solution_details and you can add into desc too 👍