repository design: monorepo dilemma

[davidkhala]

@bestbeforetoday Hi Mark, per our last call in TWGC,
community member raise a concern in the monorepo design of current fabric-gateway.

One of painpoint is git tagging implication, for a go project, the source code repos tagging is key element in version lock, but if we put multiple language source codes into one project, how to we know the v1.0.0 is for golang release or a gateway-sdk-java release?

It will be good if you can share your thinking and solution for it.

BR,
David Liu

[bestbeforetoday]

All three languages implementations provide exactly the same functionality, and every PR build runs exactly the same scenario tests against all three language implementations to ensure this. I am not sure how this would be possible if each language implementation was located in a separate repository.

Since the capability of all client languages must stay in step, the version tagging on the repository will apply to all three client languages.

[davidkhala]

@guoger 郭哥，this design LGTM，or 你会不会还有别的想法？

[bestbeforetoday]

I guess for a Go developer it might be unexpected to find a Go repository with some non-Go content. An option might be to publish tagged versions of the Go code to another repository, although then there is potential for confusion for users about where to open and track issues against the Go API. I'm not sure there is a perfect answer. What we have now seems to be the simplest at least.

@jt-nti might have opinions since he has done most of the work on build/release automation.

[jt-nti]

if we put multiple language source codes into one project, how to we know the v1.0.0 is for golang release or a gateway-sdk-java release?

That is the downside of keeping all the implementations in one repo, however the build is set up to publish a release of the Node and Java SDKs for each git tag and there are checks to make sure the versions stay in sync. That does mean that one or more of the SDK implementations could be released without any code changes but hopefully that will not cause any issues.

The alternative is for each SDK implementation to have its own repository although, as @bestbeforetoday mentioned, that would make it more difficult to ensure all three SDK capabilities are always equivalent.

[davidkhala]

I think the idea is if no change in node folder, and the build trigger its package publish process. But since node package version is unaffected, npm will prompt error like "version already exist" and we decide to let it be, ignore the "existing" error and continue.

is it?

[bestbeforetoday]

The Node and Java package versions are updated to match the git tag created in this repository on publish so a new version would be published, even if the content was the same as the previous version.