Using main branch commit in go.mod is a downgrade (0.15.1)

[runephilosof-karnovgroup]

Component

other

Describe the bug

Upgrading from v1.0.2 to the latest commit on the main branch is a downgrade, because its version is 0.15.1.

$ go get github.com/woodpecker-ci/woodpecker@3607886
go: downloading github.com/woodpecker-ci/woodpecker v0.15.1-0.20231026084608-3607886be2b2
go: downloading golang.org/x/net v0.17.0
go: downgraded github.com/woodpecker-ci/woodpecker v1.0.2 => v0.15.1-0.20231026084608-3607886be2b2
go: upgraded golang.org/x/net v0.16.0 => v0.17.0

System Info

go version go1.20.8 linux/amd64

Additional context

No response

Validations

• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Checked that the bug isn't fixed in the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
• Check that this is a concrete bug. For Q&A join our Discord Chat Server or the Matrix room.

[qwerty287]

Is it really a downgrade and you can't use funcs added in newer WP versions?
Because the line go: upgraded golang.org/x/net v0.16.0 => v0.17.0 looks more like an upgrade, but go get handles the version number of WP incorrectly.

[qwerty287]

Yes, I just tested myself, you can try with this code:

package main

import (
	"github.com/woodpecker-ci/woodpecker/woodpecker-go/woodpecker"
)

func main() {
	cl := woodpecker.New("https://ci.woodpecker-ci.org/")
	cl.RepoListOpts(true)
}

(it returns an error without token, but that's not important)

RepoListOpts has two bool args in <= 1.0, but only one in main (see #2090).
This seems to be not an issue at our end, but at Go's.

[runephilosof-karnovgroup]

It is using the correct code.
The only problem is the confusion, when you see that it thinks it is downgraded to v0.15.1 when in reality you are running v2.0-next code.

https://go.dev/ref/mod#pseudo-versions

It uses the latest tag in the main branch.

$ git tag --sort 'v:refname' --merged main|tail -n1
v0.15.0-rc2

Then it increments the patch version, throws away -rc2 and appends a pseudo version based on the date and commit hash.

So Go expects a different git workflow.

[runephilosof-karnovgroup]

It would be nice with a git workflow where the latest release branch is merged into main (instead of cherry-picking/squash merging).
That way the tags would be in main and Go would show the expected version here.

It would also make it easier to compare two branches using Github's UI. Currently, it shows release/1.0 as 41 commits ahead of main on https://github.com/woodpecker-ci/woodpecker/branches/active. But a lot of those commits exist in main as duplicates.

[runephilosof-karnovgroup]

The easiest solution would just be to tag a commit in main something like v2.0-alpha1.

[qwerty287]

It would also make it easier to compare two branches using Github's UI. Currently, it shows release/1.0 as 41 commits ahead of main on https://github.com/woodpecker-ci/woodpecker/branches/active. But a lot of those commits exist in main as duplicates.

We will probably follow this approach starting from 2.0.
Can we close this issue because it will be fixed then anyways?

[runephilosof-karnovgroup]

How about my suggestion of tagging the current head of main as v2.0-alpha1?

[qwerty287]

I'm against this because there's no release like this planned. We plan to release v2.0 in the next days/week anyways.

[runephilosof-karnovgroup]

The release of v2.0 did not fix this issue.
#2905 is related to this.

[runephilosof-karnovgroup]

And issue #2913