Re: 回复: missing tags for go chaincode developement dependencies
|
Matthew Sykes
We have chosen not to add version tags to the modules because they tend to evolve compatibly and are mostly disconnected from the fabric releases. For example, if you pull any version of fabric-chaincode-go, it should work with any version of fabric. A similar statement can be made for the protocol buffers (barring additions made to support recent versions). If we started adding tags that reflected the fabric versions, this would break the semantic versioning and require consumers to change their import paths to reflect `v2` of Fabric. If we started doing proper semantic versioning, we would end up bumping minor versions regularly and it would skew heavily from the released versions. Instead, we've chosen to stay with v0 semantics. To make a long story short, the module versioning is disjoint from the fabric versioning and in place of tags we've used branches that map to the fabric version. When you `go get` your module, you can use `@branch` to pull the latest from the branch. The `go.mod` will then be updated with the commit timestamp and hash of the repository hosting the module. We are not the only ones to do this. (See golang.org/x/{crypto,sync,sys,time.tools}). It does seem we've messed up with fabric-chaincode-go, however, since we don't have any branches there. That should probably be fixed for release-2.2+. On Tue, May 4, 2021 at 9:20 PM david liu <david-khala@...> wrote:
--
Matthew Sykes matthew.sykes@... |
|
|