Go's indexing servers didn't pick up real version number for fabric

[yurivict]

I use this script to retrieve all Go packages:

$ cat go-retrieve-all-packages.sh 
#!/bin/sh

SINCE=$1 # like 2021-08-01T00:00:00Z

while [ -n "${SINCE}" ]; do

	# download
	echo "downloading SINCE=${SINCE}"
	wget "https://index.golang.org/index?limit=2000&since=${SINCE}" -q -O output-${SINCE}.json

	# get last since
	SINCE_NEW=`tail -1 output-${SINCE}.json | sed -e 's|.*"Timestamp":"||; s|".*||'`

	# EOF?
	if [ "${SINCE_NEW}" = "${SINCE}" ] || [ -z "${SINCE_NEW}" ]; then
		echo "=== End of project list reached @ ${SINCE} ==="
		exit 0
	else
		SINCE=${SINCE_NEW}
	fi
done

For example, go-retrieve-all-packages.sh 2021-09-10T00:00:00Z

fabric is registered with incorrect versions like v0.0.0-20210916200841-1243e99c1ff2, and 2.3.3 doesn't appear there.

[yurivict]

My guess is that .mod file should contain module github.com/hyperledger/fabric/v2.

[denyeart]

I believe this was done intentionally since Fabric is a top level project and not meant to be used as a dependent library by other projects.

[yurivict]

I believe this was done intentionally since Fabric is a top level project and not meant to be used as a dependent library by other projects.

Top level projects also need to be registered on Go's indexing servers because package builders download project dependencies from there.

[denyeart]

I believe this was done intentionally since Fabric is a top level project and not meant to be used as a dependent library by other projects.

Top level projects also need to be registered on Go's indexing servers because package builders download project dependencies from there.

@yurivict I've attempted a PR to update the module to v2 but it looks like there will be too many impacts across the toolchain. Since Fabric module is not intended to be used as a dependency, can you give an example of a workflow that requires the module to be v2? If you need to build Fabric from source, why not get the source from github?

[yurivict]

Since Fabric module is not intended to be used as a dependency, can you give an example of a workflow that requires the module to be v2?

The FreeBSD's ports framework downloads modules from Go's servers. FreeBSD ports exist only for top-level projects.

[denyeart]

@yurivict I've looked at other top-level Go projects that have released beyond v1, and most don't specify a version for their top-level go module (e.g. cockroachdb, prometheus, grafana). Is there some guidance from the Go community that you can point to for top-level projects? Most of the docs I've found for go module versioning are talking about go libraries that will be consumed as dependencies.

[denyeart]

The PR proved that there were too many downstream disruptions caused by a switch to v2 for fabric module, I've had to close the PR.