v28 No matching versions for query "latest" #536
Labels
No Label
bug
duplicate
enhancement
invalid
question
up for grabs
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jcarr/git2go#536
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi,
I'm trying to import v28 into a fresh project but getting the following error when compiling:
I have libgit2 v0.28.4-1 installed.
P.S. I had v27 installed and its working fine
huh, i just tried it earlier today and worked fine :S https://github.com/libgit2/git2go/issues/535#issuecomment-586719054
what version of go are you using? there seems to be some problems with go 1.11-1.12 and modules per https://github.com/golang/go/issues/27215
do you have any other ways of helping us reproduce the issue?
I've been having this same issue:
The behavior is only present when in a directory with a
go.modfile.I'm too new to dealing with modules to know what to suggest, but I'd be happy to provide any more information that would be useful.
This is reproducible in a golang:alpine docker instance
BTW, I tried to install this via
go get -v github.com/libgit2/git2go@v0.28.4(i.e. using the tag in the repository) but git_dynamic.go is still tagged at0.27.Is this correct for how the git2go project manages tagging and releases?
Just created v0.28.4.1, that one should work.
Thank you! I didn't intend my comment to be snippy, I thought I didn't understand how this tracks libgit2. Very much appreciate this project and your efforts!
oh now i read my reply and it comes as being a bit curt. it wasn't my intention ^^;;
so far this is what i've gathered:
go get -v github.com/libgit2/git2go@v0.28.4.1works, since that is using the exact tag name and requires no further processing from the tools. but that is a bit cumbersome to use :Sv28, which is going to point tov0.28.xinstead ofv1.x.y!v100forv1.0.0andv101forv1.1.0let me ask around and see if there are any good options i'm missing.
after reading a bit more, i have a proposal.
release-${LIBGIT_MAJOR_VERSION}.${LIBGIT_MINOR_VERSION}will be created. that way people can refer to these branches unambiguously fromgo getusinggo get -v github.com/libgit2/git2go@release-0.28, since branches that start withv${number}are treated as semver and are completely ignored.vXbranch will be created. TheXwill be independent of libgit2's version. Since we already havev27andv28branches, this will start inv29for libgit2 0.99. that has the implication that if there is ever a minor release that introduces a breaking API change (from Go's perspective), that would warrant a git2go major version bump for that release AND formaster.this might make it a bit unwieldy to use with gopkg.in, but given that the tooling has improved in the last months, it might be okay in the end. if there are no major concerns, this will be implemented some time next week now that libgit2 0.99.0 has been released and we would need to create new branches anyways.
FWIW this sounds good to me. I worked on bindings for ZK for a long time, and I know how difficult it is when you need to have two versions that you're representing with one name.
I'm generally of the opinion that releases should be tagged, that way there's an unambiguous pointer with human meaning given to a specific revision of the code. Repeatability is generally the primary concern that I have.
That being said, and in my (admittedly inexpert) reading of the go.mod docs regarding the role of
go.sumI believe that repeatable builds are baked in through other means, so using a branch seems to be a fine approach. I like the idea of having the specificrelease-${MAJOR}-${MINOR}branches, and thev${semver}being separate concerns. The problem that led me here was that brew installsv28, but I couldn't get the matching git2go version to install, which was the beginning of something of a wild goose chase, as I'm not quite up to speed on the go packaging tooling. It sounds like having therelease-${MAJOR}-${MINOR}branches would have worked well for me.Again, thank you for your efforts, and for giving careful thought to this issue. I find this project immeasurably useful (especially since it means I don't have to go learn C++, which some others are strong advocates for). Cheers! :)
All right, all tags have been created and now gopkg.in is much happier.
v29now points to libgit2 0.99.