Fabric v2.5 release

[denyeart]

Umbrella epic to capture misc items for Fabric v2.5 release.

This does not include #2787 which is also targeted for v2.5.

[davidkhala]

Hi @denyeart
https://go.dev/ref/mod#incompatible-versions

Do we have plan to referring this module name convention on module in format of ../v2 in next LTS 2.5 release?

[SamYuan1990]

@denyeart , @jkneubuh
I hope we are able to have v2 as api release.
for example, when developing admin-sdk, for peer join channel feature.
I noticed that there some code depends on package "github.com/hyperledger/fabric/core/scc/cscc"
which is not included in current api for go mod, so I hope we are able to release 2.5 with v2 api so that cscc package can be invoked by "github.com/hyperledger/fabric/v2/core/scc/cscc"

[SamYuan1990]

I made a pr for sample, hope it works. #3529

[yacovm]

Hi @denyeart https://go.dev/ref/mod#incompatible-versions

Do we have plan to referring this module name convention on module in format of ../v2 in next LTS 2.5 release?

Fabric core is not supposed to be imported/vendored by external projects.
That's part of the reason we have repositories for everything starting from protos, shim, idemix, and even channel configuration.

[SamYuan1990]

Hi @denyeart https://go.dev/ref/mod#incompatible-versions
Do we have plan to referring this module name convention on module in format of ../v2 in next LTS 2.5 release?

Fabric core was never meant to be imported/vendored by external projects. That's part of the reason we have repositories for everything starting from protos, shim, and even channel configuration.

hi @yacovm ， in that case, if we want to develop admin sdk to allow peer join channel instead of use peer cli, as the code logic depends on github.com/hyperledger/fabric/core/scc/cscc and as you said, if we don't have plan to expose fabric core...
any suggestion to make the admin sdk without fabric core?

[yacovm]

Hi @denyeart https://go.dev/ref/mod#incompatible-versions
Do we have plan to referring this module name convention on module in format of ../v2 in next LTS 2.5 release?

Fabric core was never meant to be imported/vendored by external projects. That's part of the reason we have repositories for everything starting from protos, shim, and even channel configuration.

hi @yacovm ， in that case, if we want to develop admin sdk to allow peer join channel instead of use peer cli, as the code logic depends on github.com/hyperledger/fabric/core/scc/cscc and as you said, if we don't have plan to expose fabric core... any suggestion to make the admin sdk without fabric core?

Why do you need to import the server side code to be able to implement a client? The logic that CSCC performs is unrelated to what you need to send to a chaincode. Just assemble the payloads it expects and send it to a chaincode, what's the issue?

[yacovm]

and as you said, if we don't have plan to expose fabric core...

I think in v3 we would end up making a module inside Fabric core that will be importable, and will abide by the Go module conventions, but that doesn't mean we need to make all of Fabric core a huge module.

[SamYuan1990]

Hi @denyeart https://go.dev/ref/mod#incompatible-versions
Do we have plan to referring this module name convention on module in format of ../v2 in next LTS 2.5 release?

Fabric core was never meant to be imported/vendored by external projects. That's part of the reason we have repositories for everything starting from protos, shim, and even channel configuration.

hi @yacovm ， in that case, if we want to develop admin sdk to allow peer join channel instead of use peer cli, as the code logic depends on github.com/hyperledger/fabric/core/scc/cscc and as you said, if we don't have plan to expose fabric core... any suggestion to make the admin sdk without fabric core?

Why do you need to import the server side code to be able to implement a client? The logic that CSCC performs is unrelated to what you need to send to a chaincode. Just assemble the payloads it expects and send it to a chaincode, what's the issue?

ref to line

fabric/internal/peer/channel/join.go

Line 67 in 0fa4d2f

input := &pb.ChaincodeInput{Args: [][]byte{[]byte(cscc.JoinChain), gb}}

so... instead of using fabric core modules, another option is that we open those const values? or user copy paste those const value into their own code?

[yacovm]

Hi @denyeart https://go.dev/ref/mod#incompatible-versions
Do we have plan to referring this module name convention on module in format of ../v2 in next LTS 2.5 release?

Fabric core was never meant to be imported/vendored by external projects. That's part of the reason we have repositories for everything starting from protos, shim, and even channel configuration.

hi @yacovm ， in that case, if we want to develop admin sdk to allow peer join channel instead of use peer cli, as the code logic depends on github.com/hyperledger/fabric/core/scc/cscc and as you said, if we don't have plan to expose fabric core... any suggestion to make the admin sdk without fabric core?

Why do you need to import the server side code to be able to implement a client? The logic that CSCC performs is unrelated to what you need to send to a chaincode. Just assemble the payloads it expects and send it to a chaincode, what's the issue?

ref to line

fabric/internal/peer/channel/join.go

Line 67 in 0fa4d2f

input := &pb.ChaincodeInput{Args: [][]byte{[]byte(cscc.JoinChain), gb}}

so... instead of using fabric core modules, another option is that we open those const values? or user copy paste those const value into their own code?

Just copy the string :-)

[denyeart]

@davidkhala @SamYuan1990
I agree with Yacov, we don't want to signal that people should import core Fabric code.