The 3.0.1 branch is essentially inaccessible through gopkg.in simply because of the existance of the v3 branch?
From a branch naming perspective, aren't v3, v3.0, and v3.0.0 semantically equivalent?
As a library consumer, I would expect a v3 selector to always give me the latest branch out of v3, v3.x, v3.x.y
As a library consumer, I would expect a v3 selector to always give me the latest branch out of v3, v3.x, v3.x.y
--
You received this message because you are subscribed to the Google Groups "Go Package Management" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-package-manag...@googlegroups.com.
To post to this group, send email to go-package...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
What is the rationale for having a special case for exact matches?The 3.0.1 branch is essentially inaccessible through gopkg.in simply because of the existance of the v3 branch?
I wish there was an option to *not* allow this auto-upgrade behavior.
On Tue, Mar 25, 2014 at 11:54 AM, Pavan Kumar Sunkara
<pavan....@gmail.com> wrote:
> What if v3.3 contains a minor breaking change that Package B doesn't want?
That's ignoring what the major version v3 means to people. No such
minor breaking changes should be introduced without also changing the
major version to v4.
I wish there was an option to *not* allow this auto-upgrade behavior. It's actually not what I would expect by default. I would expect that if I say v2, that I get v2 and no other. Now, for some projects, getting "the most recent v2.x" is fine... but I think for a lot of projects, they'd prefer to be able to test new changes *before* they get automatically included in new builds.
My ideal behavior would be: v2 (without minor version specified) means "use the latest 2.x", and v2.3 (explicitly choosing a minor version) means "use this exact version and no other". Yes the latter requires manually updating when you want to move to 2.4, but it lets me gate upstream changes on my own terms. It's the more paranoid choice for people who really need their stuff not to break.\
--
gopkg.in/pkg/v3 => github.com/go-pkg/pkg-v3
I agree with the version numbering.
Do you sleep? ;) keep up the good work!
Kyle Lemons wrote:Why not use a tag or branch?
> Probably the biggest thing preventing me from using gopkg.in for my own
> random projects is that having gopkg.in/kylelemons/v2/gousb as the latest
> when I'm working on gopkg.in/kylelemons/v10/rx seems strange. If I were
> browsing it as a filesystem, I'd click on v10 and see that only one package
> exists, and assume that I gave up on the rest. I would much prefer
> gopkg.in/kylelemons/gousb/v2, despite the slight awkwardness that v2 isn't
> the imported name.
The two main reasons it ended up earlier in the path is to have the
package name last, which I hope we can agree looks nice, and to
preserve the general pattern of pkg/subpkg. With a version last,
packages and subpackages would be split apart by the version:
http://gopkg.in/you/pkg/v3
http://gopkg.in/you/pkg/v3/sub