SemVer

[Matt Farina]

I'm curious what it would take to get a SemVer recommendation to the Go community in mass.

The tools for at least Rust, Elixir, Erlang, Ruby, and JavaScript already have this. PHP, Python, and Perl are a few that aren't explicit but generally follow SemVer implicitly. I believe this second group all had their specs for this before SemVer was formalized.

The Go community has at least 3 package managers that support SemVer in Glide, GB, and Govendor.

There are multiple packages to work with SemVer (ref, ref, ref, and numerous others).

Go itself essentially uses SemVer (aside from the tags starting with go instead of a v).

GitHub itself recommends SemVer for releases. This is where Go and many of the common packages live today. It says,

Tagging suggestions

It’s common practice to prefix your version names with the letterv. Some good tag names might bev1.0 or v2.3.4.

If the tag isn’t meant for production use, add a pre-release version after the version name. Some good pre-release versions might be v0.2-alpha or v5.9-beta.3.

Semantic versioning

If you’re new to releasing software, we highly recommend reading about semantic versioning.

I've not heard of a good alternative. It would be useful today to get a recommendation out of the Go core team. Maybe a blog post recommending it on blog.golang.org.

Is this something we can do sooner rather than later? Or, does someone have a case to make to put this step off to some future point. 

[Matt Farina]

I forgot to mention it but, of the projects that do tag releases the overwhelming number (IIRC >99%) already use SemVer. I've run the numbers a couple times over the past 6 months. There has been growth of people tagging releases in that time as well.

[Dave Cheney]

Thanks for opening this discussion Matt. I believe for this to happen it must be explicitly endorsed by active members of the Go team. 

--
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.

[Andrew Gerrand]

Dave proposed this: https://github.com/golang/go/issues/12302

Russ objected, saying:

...my objection is that this proposal does not propose any actual changes to any part of Go. It is not actionable in its current form. I'm still not even sure it's a good idea, in large part because one way I evaluate whether something is a good idea is to understand its effects, and this proposal has no direct effects. 

Build a system that uses semantic versions effectively. Demonstrate what great tools can be built. Give people incentives, and they will tag their releases no matter what the Go team says. Certainly the Go team saying "you should do it this way" has not in the past been successful without these things (think not-vendoring).

Which, I think, is a reasonable stance to take. But now we do have package managers that support semver (such as glide), so maybe the objection is not so relevant.

I think we can enshrine this convention when we standardize a vendor spec (or manifest/lock files). Is there a compelling reason to get this done ahead of that? AFAICT everyone involved seems to agree that semver is the right choice for expressing package versions.

Andrew

[Dave Cheney]

I would like to see a recommendation on tagging remain separate to a discussion on the vendor spec.

They are related, but conflating two contentious things doesn't make them less contentious.

I would not like to see a decision on recommending a tagging format delayed by extended debate on the vendor spec any more than the vendor spec proponents would like to see their proposal delayed by an extended debate on semver.

[Matt Farina]

Here are a few points to ponder:

• When Dave started the proposal no package manager supported SemVer. Glide added it while the proposal was being discussed but it was still new and no one else did. Now we have 3 package managers (at least) in the wild that support it and the support has proven to be useful (speaking at least for Glide).
• Does best practice in Effective Go have a tool in the toolchain checking (linting, vetting, etc) it? I think there are some not covered. Isn't it ok to have a best practice not explicitly linked to a tool?
• In software it's generally considered a best practice to use releases and not just pull from the tip of master. Go does it. Even OpenStack projects, which are considered generally safe to run as the tip of master, release multiple times per year for those that use releases. Wouldn't this be suggesting a format for what already should be a best practice for shipped software?

When it comes to tools that have version resolvers (today I'm aware of gps and glide being the two so this is a bit personal) it's harder to work with revisions than versions when figuring out what to use. For example, a project might import 3 other projects. 3 of the 4 projects have a shared 5th project and each does so at a different revision. Which should you flatten the tree to use? It's a much easier problem when you have versions with meaning.

This is one of the reasons SemVer and version schemes really close to SemVer are so popular. They are great for those writing resolvers to work out meaning and intent.

This is obviously a problem that relates to me and others may not be interested in it as a valid reason at the moment.

Andrew, thanks for reminding me that Russ said...

...my objection is that this proposal does not propose any actual changes to any part of Go. It is not actionable in its current form.

Given this I have a couple ideas that may be able to fulfill the actionable element in a way we can all mostly agree on. If we have something there sooner rather than later would any blockers be removed?

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

[Sam Boyer]

On Wednesday, July 20, 2016 at 6:19:51 PM UTC-4, Andrew Gerrand wrote:

Dave proposed this: https://github.com/golang/go/issues/12302

Russ objected, saying:

...my objection is that this proposal does not propose any actual changes to any part of Go. It is not actionable in its current form. I'm still not even sure it's a good idea, in large part because one way I evaluate whether something is a good idea is to understand its effects, and this proposal has no direct effects. 

Build a system that uses semantic versions effectively. Demonstrate what great tools can be built. Give people incentives, and they will tag their releases no matter what the Go team says. Certainly the Go team saying "you should do it this way" has not in the past been successful without these things (think not-vendoring).

Which, I think, is a reasonable stance to take. But now we do have package managers that support semver (such as glide), so maybe the objection is not so relevant.

Yep - while I found it frustrating, I couldn't really argue with the conclusion. I've described this in the past as one of our great catch-22s: https://github.com/Masterminds/glide/issues/479#issuecomment-227269753

 

I think we can enshrine this convention when we standardize a vendor spec (or manifest/lock files). Is there a compelling reason to get this done ahead of that? AFAICT everyone involved seems to agree that semver is the right choice for expressing package versions.

Yeah, I think that's definitely the right concrete change to the lang/tooling to which "formal" semver adoption should be tied.

However, in the interim, there's two things that I think could be helpful:

1. Signaling, in some public kind of way, that this is probably the direction that the ecosystem will officially be headed

2. Coming up with some formal rules about what kinds of exported interface changes necessitate what kinds of semver bumps, then encoding those into a tool: compare the current working directory with the last semver tag/a named semver tag, and suggest the next semver version that should be applied based on the differences. (https://github.com/motemen/gompatible is the most adjacent thing to such a tool that I'm aware of)

 

Andrew

[jo...@souvestre.com]

> Is this something we can do sooner rather than later?

Sooner, I hope. I agree that if the Go team were to lead the way it would help. They could show support by using SemVer. I'm thinking of two specific items which could be brought into full SemVer compliance.

1) runtime.Version

2) Go's filenames for releases.

Both are close, but don't quite fully conform. If these were fixed I think it would send a clear signal.

[jo...@souvestre.com]

and

3) Build tags.

[Andrew Gerrand]

John, can you elaborate on what you mean by points 1, 2, and 3?

--
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.

[Andrew Gerrand]

On 20 July 2016 at 16:12, Matt Farina <matt....@gmail.com> wrote:

Given this I have a couple ideas that may be able to fulfill the actionable element in a way we can all mostly agree on. If we have something there sooner rather than later would any blockers be removed?

What are those ideas?

[jo...@souvestre.com]

On Thursday, July 21, 2016 at 8:47:23 AM UTC-5, Andrew Gerrand wrote:
> John, can you elaborate on what you mean by points 1, 2, and 3?

I believe that the strings don't exactly meet the SemVer 2 standard, and would need to be changed a bit.

Note: I don't believe that SemVer allows for a "prefix" field. It probably should, and I've seen others use "-" to delimit it. So that is what I'm showing below.

1) runtime.Version

"go1.6.3" ==> "go-v1.6.3".

The current function can alternately return a commit hash and build data.

Given this, and possible problems with backward compatibility, I'm thinking that the best solution might be to add a separate function: runtime.SemVer()

2) Go's filenames for releases.

"go1.6.src.tar.gz" ==> "go-v1.6.0+src.tar.gz"
"go1.7rc3.src.tar.gz" ==> "go-v1.7.0-rc3+src.tar.gz"

3) Build tags.

For a specific version: (not supported now) ==> "// +build go-v1.6.0"
For a range of versions: "// +build go1.6" ==> "// +build go-v1.6.0 - go-v1.7.0" (open, close)
Wildcards and other shortcuts: Not in the SemVer standard, but there are some in common usage, for example: "// +build go-v1.6.*"

[Sam Boyer]

(sorry John, sent to just you initially)

The contexts to which you'd like to apply semver here make a lot of
sense, and I also think that it should be a short hop from what Go does
right now to semver.

However, "it probably should" is the sound made by a standard getting
forked. Please, let's not do that.

If it's strictly necessary for the lang itself to include a "go-" prefix
in contexts such as these, then OK - but let's treat that prefix as a
clearly separate component that is handled by something on top of, but
separate from, a proper semver implementation.

[jo...@souvestre.com]

I agree. We don't want to "stretch" the standard. But I'm thinking that if the string is spec'ed as "go-" followed by a SemVer, that would be acceptable. What do you think?

[Sam Boyer]

yep, +1 from me.

[Daniel Haskin]

I have thought about the SemVer question a lot, and I had some thoughts.

I feel that standardization when it comes to versions is often best done by standardizing the algorithm. This is what RPM and APT do -- they specify their version comparison algorithm. Doing this allows many schemes to happen while encouraging the right one.

I've personally felt lots of pain in the python/pip community recently. Python standardized on its version numbering scheme also. Recently, pip implemented the change, rejecting packages with an improper version number. But then some developer out there had an incomaptible version number. The package was thrown out, and all of a sudden lots of my builds broke. :(

If we, for example, standardized on a similar versioning algorithm to that of RPM's, but with the following changes:

• Anything before a '~' character is ignored.
  
• Anything after a '+' character is ignored.
• If a 'v' character appears immediately following a blank or punctuation token, and immediately before a number token, it is ignored.

These changes would:

• Support semver 2.0 compliant strings
• Support ignored prefixes ('go~' and others)
• Support 'v' prefixes, as in 'v1.3.2'
• etc.

Then, if semver were violated by the version number, a warning would be printed, asking e.g. the package maintainer to "please" change the version number to be compliant or that a non-compliant number is "not recommended", etc. Then builds wouldn't break, but it would become apparent that semver is the way people should use the tool.

[Konstantin Khomoutov]

On Fri, 22 Jul 2016 10:52:52 -0700 (PDT)
Daniel Haskin <djhas...@gmail.com> wrote:

[...]

> If we, for example, standardized on a similar versioning algorithm to

> that of RPM <http://rpm.org/api/4.4.2.2/rpmvercmp_8c-source.html>'s,

> but with the following changes:
>

> - Anything before a '~' character is ignored.
> - Anything after a '+' character is ignored.
> - If a 'v' character appears immediately following a blank or

> punctuation token, and immediately before a number token, it is
> ignored.

[...]

FWIW, [1] is how APT (dpkg, actually) interprets versions.

1. https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

[jo...@souvestre.com]

As I read it, the SemVer 2.0.0 spec does include a fairly rigorous ordering algorithm.  It's in paragraph #11.  I believe it covers all of the cases you mentioned, except for using a '~' to delimit prefix (before the SemVar) info.

Please note that the leading 'v' is required.  I believe that it used to be optional, but is required now.

[jo...@souvestre.com]

On Friday, July 22, 2016 at 4:44:59 AM UTC-5, jo...@souvestre.com wrote:

"go1.7rc3.src.tar.gz"  ==> "go-v1.7.0-rc3+src.tar.gz"

Correction, it should go to:  ==> "go-v1.7.0-rc.3+src.tar.gz" 

Otherwise rc3 would sort after rc11.  :)

[Daniel Haskin]

Not completely. In the debian version algo, everything after the '~' is
ignored, but as a suffix instead of a prefix. Further, versions with the
tilde sort before versions without. For example, 1.2~alpha would sort before
`1.2`. I am suggesting no such special ordering :), only that contents
coming before the tilde be ignored. I do appreciate the link, though.
Debian's versioning algorithm is a good one.

Honestly, though, the way the rpm vercmp algo is written, you could simply
use 'go-' with a hyphen, and as long as the package maintainer consistently
used this prefix, the effect would be the same under that algo.

[jo...@souvestre.com]

On Wednesday, July 20, 2016 at 3:43:03 PM UTC-5, Matt Farina wrote:

I'm curious what it would take to get a SemVer recommendation to the Go community in mass.

I'm thinking that the easier it is to do and the more Go seems to support it in a uniform fashion (rather than each package manager having its own style), the more acceptance there will be.

Also, I like the idea of having any version dependency constraints as close to the code which necessitates them as possible.

Thus I'm proposing (again?) that version info be added to Go's import command, on a per-package basis.  I've read some earlier comments that this would not be possible due to the compatibility guarantee.  I'm suggesting that it be done as an option, thus not breaking any present code.  If this isn't acceptable, how about a special comment (prefix of '+' like the build's) on the same line as the package name?  The two formats would look something like these:

import (

    widget v1.2.3 - v1.2.*

[OR]

    widget // +v1.2.3 - 1.2.*

)

This is somewhat similar to what Perl allows, and I found it quite natural.

Another thing which Perl encouraged was setting a "Version" string in each module (package).  This allowed not only static inspection but also run time switches to be implemented.  It allowed writing code which could interface with different API versions.

[Daniel Haskin]

Sorry, replied to you, but didn't post to the group as well :) Reply to this below.

SemVer’s spec includes a good algorithm, but it can only be used if it is comparing two compliant versions. To be clear, I am suggesting we use a versioning algorithm which supports semver, but doesn’t require it. Then, the tool which uses this algo can still detect non-semver compliant versions and print a warning or suggestion, while still maintaining the ability to do its job regardless of the messiness of life and the quirks of non-compliant packages. I cited RPM’s version algo as an example of a version sorting algorithm that works well, but supports many different versioning schemes, provided the use of any given scheme is consistent.

[jo...@souvestre.com]

On Friday, July 22, 2016 at 1:33:38 PM UTC-5, Daniel Haskin wrote:

Not completely. In the debian version algo, everything after the '~' is
ignored, but as a suffix instead of a prefix.

I believe that SemVer does this also, but uses '+' for the suffix (build metadata, but can be anything) delimiter.

 

[jo...@souvestre.com]

On Friday, July 22, 2016 at 1:39:43 PM UTC-5, Daniel Haskin wrote:

SemVer’s spec includes a good algorithm, but it can only be used if it is comparing two compliant versions. To be clear, I am suggesting we use a versioning algorithm which supports semver, but doesn’t require it. Then, the tool which uses this algo can still detect non-semver compliant versions and print a warning or suggestion, while still maintaining the ability to do its job regardless of the messiness of life and the quirks of non-compliant packages.

I don't understand the advantage of allowing non-spec strings.  We aren't burdened with legacy issues, are we?

If so, fine.  But if not, I don't see the advantage of allowing an incorrect format which needs to be fixed.

[Peter Bourgon]

I strongly agree with John. Let's not preëmptively carve out exceptions.

[Sam Boyer]

Ah, so, this is an important line to draw, I think: we have to delineate
between *preferring* or *prioritizing* semver, versus *requiring* semver.

Requiring implies that it is, in some way, not possible to create a
release without conforming to a particular version string. In that
sense, the ecosystem we have right now cannot *require* semver. All we
have to act on is vcs data, and we can't prevent the creation of
nonconforming tags. All we can do is design tools that prioritize,
prefer, or ignore tags that do not conform to semver. (Note that I'm not
advocating a central registry - just clarifying this point)

Given that we can't prevent people from publishing such releases, it
only makes sense to allow them, even if deprioritizing them relative to
semver. Which goes back to your idea that the algorithm is what matters.

(I see from a later email that this is basically what you were suggesting)

Today, glide works that way to an extent, and gps fully and formally
works that way.

On 7/22/16 13:52, Daniel Haskin wrote:
> I have thought about the SemVer question a lot, and I had some thoughts.
>
> I feel that standardization when it comes to versions is often best done

> by standardizing the /algorithm/. This is what RPM and APT do -- they

> specify their version comparison algorithm. Doing this allows many
> schemes to happen while encouraging the right one.
>
> I've personally felt lots of pain in the python/pip community recently.
> Python standardized on its version numbering scheme also. Recently, pip
> implemented the change, rejecting packages with an improper version
> number. But then some developer out there had an incomaptible version
> number. The package was thrown out, and all of a sudden lots of my
> builds broke. :(
>
> If we, for example, standardized on a similar versioning algorithm to

> that of RPM <http://rpm.org/api/4.4.2.2/rpmvercmp_8c-source.html>'s, but
> with the following changes:
>
> * Anything before a '~' character is ignored.
> * Anything after a '+' character is ignored.
> * If a 'v' character appears immediately following a blank or

> punctuation token, and immediately before a number token, it is ignored.
>
> These changes would:
>

> * Support semver 2.0 compliant strings
> * Support ignored prefixes ('go~' and others)
> * Support 'v' prefixes, as in 'v1.3.2'
> * etc.
>
> Then, if semver were violated by the version number, a /warning/ would

> be printed, asking e.g. the package maintainer to "please" change the
> version number to be compliant or that a non-compliant number is "not
> recommended", etc. Then builds wouldn't break, but it would become

> apparent that semver is the way people /should/ use the tool.

>
>
> On Friday, July 22, 2016 at 11:18:24 AM UTC-6, Sam Boyer wrote:
>
> yep, +1 from me.
>

> On 7/22/16 13:08, jo...@souvestre.com <javascript:> wrote:
> > I agree. We don't want to "stretch" the standard. But I'm
> thinking that if the string is spec'ed as "go-" followed by a
> SemVer, that would be acceptable. What do you think?
> >
>

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "Go Package Management" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/go-package-management/PyQte5OXvYs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> go-package-manag...@googlegroups.com
> <mailto:go-package-manag...@googlegroups.com>.

> To post to this group, send email to
> go-package...@googlegroups.com

> <mailto:go-package...@googlegroups.com>.

[Sam Boyer]

This list has explored the problems with putting dependency constraints
directly in the source before. The short, sorta-glib reason is "don't do
that, because time and space are separate dimensions."

I give a longer, more detailed answer in this article:
https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527

On 7/22/16 14:38, jo...@souvestre.com wrote:
> On Wednesday, July 20, 2016 at 3:43:03 PM UTC-5, Matt Farina wrote:
>

> I'm curious what it would take to get a SemVer <http://semver.org/>

[Sam Boyer]

(though, a tool implementing gps could choose to only allow valid semver
tags)

[John Souvestre]

> I give a longer, more detailed answer in this article:
> https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527

I enjoyed your article very much, but I don't recall where you discussed this. Could you point me at it? Thanks.

I realize that I left something out of my previous post. I was not suggesting that the Go compiler would be involved in dealing with the version info. I was just thinking that a package manager could harvest the version info automatically to populate/update its config file.

>> Also, I like the idea of having any version dependency constraints as
>> close to the code which necessitates them as possible.

I might grab a file from a co-worker to modify and use in my project. This way I'll see any import version limitations at the file level, without have to look at his project's config file and wonder if those limitations apply to the file I'm grabbing or not.

Another advantage is the reduction of stale version dependencies when refactoring. Say I revise a package so it no longer needs a limitation. Currently I would have no easy way to tell if the limitation in the project's config file can be removed or not.

[Sam Boyer]

Thanks! :)

Sadly, medium makes it impossible for me to direct link. It's a few images up from where "To Manifest a Manifest" starts. searching for "bizarro" in the page will drop you in the middle.

To be fair, it is (also) a brief and more...metaphorical part of the essay. So, here are some more concrete reasons/thoughts:

1. Declaring at the file level introduces the possibility of disagreement on constraints between import statements in files within a package. Or, more fun, disagreement between imports in files that have mutually exclusive build tags. These are not unsolvable problems, but the only thing that can truly *enforce* rules is the compiler (people can still write Go code w/out the standard package manager), so
   
2. Extending the last, what about different packages within your project (e.g., github.com/foo/bar and github.com/foo/bar/baz) expressing differing import constraints on the same package? Does the answer change if gh/foo/bar and gh/foo/bar/baz are not transitively import-reachable from each other? What if neither transitively imports the other, but they have a shared internal dep (gh/foo/bar -> gh/foo/bar/qux, gh/foo/bar/baz -> gh/foo/bar/qux)?
   
3. Whatever the answers are to the last two, how do you make the rule clear enough that people don't screw it up all the time? What about the maintenance burden of keeping all those declarations in sync, whether or not there's a formal rule? What do you do with imported dependencies that have some inconsistencies, at least at some versions - do you throw them out?
   
4. Even if constraitns are recorded directly in import statements, it doesn't help at all with reproducible builds. So you still need a separate, lock-type file. So it's not like we're getting away from metadata.
5. There's no space left for expressing things like overrides, where (only) the root project can designate different constraints for some dependencies in order to resolve conflicts in the depgraph
6. There's also no capacity for projects to declare constraints on their transitive dependencies. This could be important when working with legacy code (read: literally all Go code that exists today) where no constraints are specified.

Now, to be fair, this is something that at least kardianos and I have partially disagreed on in the past. I think it's usually important to respect the atomicity of revisions in source repositories. He's less convinced. But the combinatorial explosion of constraints here concerns me that it would not scale well into complexity. I don't think it's worth eating this fractal for a convenience that could be mostly, if not entirely, offset by tooling.

[Sam Boyer]

Ugh, sorry, didn't finish editing the first bullet there. It should have been: 

"Declaring at the file level introduces the possibility of disagreement on constraints between import statements in files within a package. Or, more fun, disagreement between imports in files that have mutually exclusive build tags. Do we use the intersection of the constraints? Do we error? What throws that error? It's not the compiler (which we agree is right out), but we also can't truly enforce that people use a particular tool, even if it is the official one."

[John Souvestre]

> 1.  "Declaring at the file level introduces the possibility of disagreement on constraints ...

 

I have a different perspective.  I believe that the possibility is there - always.  It's just a matter of who detects it and handles it.  I'm for automating it as much as possible.  Depending on the user to do it means that it probably won't get done well or done correctly.  Certainly the PM  (package manager) can't be expected to resolve all such issues.  The most important task is to assemble an accurate list (best done by the PM), then attempt to resolve them (leaving unresolvable ones up to the user). This also reduces the technical debt in the form of needless constraints.

 

> 2.  Extending the last, what about different packages within your project ...

 

I appreciate that there are all kinds of nasty possibilities.  But these exist regardless.  Indeed, the more fine-grained (file level) the version info is the more nasty cases will surface.  This is good.  It is better to identify as many of the problems as possible!  :)

 

> 3.  Whatever the answers are to the last two, how do you make the rule clear enough ...

 

It's the same "rule" as a user would place in the PM's config file, just in his code's file instead.

 

> What about the maintenance burden of keeping all those declarations in sync, ...

 

Sync?  You place the dependency version limitation where it is needed.  Perhaps I'm not understanding, but I don't see where there is any synchronization involved.

 

>  What do you do with imported dependencies that have some inconsistencies, at least at some versions - do you throw them out?

 

If the dependencies are incorrect, then they need to be fixed.  If not, then the user has to work to resolve them somehow.  Again, this is true regardless of how the dependency version limitations make it to the PM's config file.  An advantage of the fine-grained (per code file) method I'm proposing is that there will be fewer mistakes (overlook and/or bogus limitations).

 

> 4.  Even if constraints are recorded directly in import statements, it doesn't help at all with reproducible builds. So you still need a separate, lock-type file.

 

Correct.  My idea is just to automate gathering the version info to put in the PM's config file.  Past that the PM would operate as normal.

 

> 5.  There's no space left for expressing things like overrides, ...

 

You could allow for manual overrides in the PM's config file.  They would just have to be marked as such - which is a good thing for readability later.

 

> 6.  There's also no capacity for projects to declare constraints on their transitive dependencies.

 

The PM would continue to have the same features as before.

 

> But the combinatorial explosion of constraints here concerns me that it would not scale well into complexity.

 

The PM is already reading all the files to get the imports.  This is just some additional data on that same line.  So it wouldn't increase file i/o.  It would add some computation, yes, but my thought is that it is much more accurate and efficient for a computer to this than the user.

 

Also, let's remember that individual imports in a package are not normally going to have version dependencies.  So we are talking about somewhat rare occurrences - hence not much extra computer time.

 

> I don't think it's worth eating this fractal for a convenience that could be mostly, if not entirely, offset by tooling.

 

I get the feeling that you aren't quite grokking my proposal.  I think that it's much more than just a convenience.  Hopefully the above answers will help to better explain my thinking.

 

 

.

[John Souvestre]

P.S.

 

To underscore a point I made above:  This could be implemented by a totally stand-alone program.  All it would do is to scan the file to build the version info to put in the PM’s config file.

 

With one exception:  The PM’s config file would need some mark to show a manually entered override.

 

[John Souvestre]

P.P.S.

 

One other thing just occurred to me.  Consider it from the view of a programmer about to release a package for general use.  But there needs to be a version limitation on one of the imports.  How does he currently convey this information to all of the users of his package?  He could put it in the documentation.  Good, but many will miss it.  Those who don’t will have to manually add it to their PM’s config.

 

Or, he could set up a PM just for this one package and include its config file.  This takes him some time, but it automates it for the users, assuming that their PMs can read his PM’s config.

 

Or, following my idea, he adds the version info to the import line where it is needed (and document it for those not using PMs).

 

Which do you think he prefers?  Given equal results, the easiest path is the one he will prefer.  J

 

John

    John Souvestre - New Orleans LA

[Eric Johnson]

Hi John,

On 7/22/16 2:50 PM, John Souvestre wrote:
>
> P.P.S.
>
> One other thing just occurred to me. Consider it from the view of a
> programmer about to release a package for general use. But there
> needs to be a version limitation on one of the imports. How does he
> currently convey this information to all of the users of his package?
> He could put it in the documentation. Good, but many will miss it.
> Those who don’t will have to manually add it to their PM’s config.
>

Libraries should have a metadata file indicating dependencies just like
main programs, shouldn't they? So this shouldn't just be hidden in
documentation.

>
> Or, he could set up a PM just for this one package and include its
> config file. This takes him some time, but it automates it for the
> users, assuming that their PMs can read his PM’s config.
>

This seems like an argument for standardizing the package manager config
file....

>
> Or, following my idea, he adds the version info to the import line
> where it is needed (and document it for those not using PMs).
>

Seems to me like this is potentially just an optimization. Most
libraries will have multiple files, and they will want to centralize
their dependency constraints in one place.

>
> Which do you think he prefers? Given equal results, the easiest path
> is the one he will prefer. J
>

This strikes me as an argument about simple vs. easy:
https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md

It may be easy to put version constraints on imports, but it feels to me
like it runs contrary to Go's aim to simplify.

Eric.

>
> John
>
> John Souvestre - New Orleans LA
>

> *From:*John Souvestre [mailto:Jo...@Souvestre.com]
> *Sent:* 2016 July 22, Fri 16:23
> *To:* 'Go Package Management'
> *Subject:* RE: [go-pm] Re: SemVer

>
> P.S.
>
> To underscore a point I made above: This could be implemented by a
> totally stand-alone program. All it would do is to scan the file to
> build the version info to put in the PM’s config file.
>
> With one exception: The PM’s config file would need some mark to show
> a manually entered override.
>

> --
> 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

[Sam Boyer]

(Responding here to all three notes)

Hm, yes, I do think I missed part of your proposal - I didn't realize you were suggesting that these file-level constraints be declared in addition to a manifest file. Now, if you were suggesting they were *only* guides to be used by such a stand-alone program for the purposes of building a manifest file, but ignored when the solver works through, then...well, maybe I could be convinced?

However, suggesting that they be used *as part of* the version selection process...I guess, in tandem with a manifest file? To my mind, that makes it worse than I initially imagined.

First, let's be clear: a file-level import restriction makes no sense in Go. Files are not the level at which the compiler operates; packages are the unit of compilation, and thus for compatibility checking. As far as I can think, the benefits you're saying would arise from this would be even greater if, say, we created a syntax that let you annotate individual lines containing references to other packages with a constraint. It tells us exactly where the need for the constraint arises from, and tools could be taught to read it in all the same ways. Yes, it's more CPU and a tad more I/O to do the additional parsing, but in a good design, that's cacheable for deps, so that alone isn't enough of a reason not to do it.

But declaring constraints at the level of individual expressions, or functions, or files, doesn't make sense, because that's not the unit of dependency that the compiler specifies.

Basically, I'm taking issue with the idea that "these complexities exist regardless." Yes, each and every individual symbol could be the thing that induces a constraint, but the spec/compiler's rules entail that question is ultimately asked at the package level. Thus, people only write Go code in a way where everything in a package (at the very least) is reliant on the same version of its dependencies. Allowing declarations to get more granular than that not only goes against the grain, but it creates a whole new class of possible ways that Go code can be internally inconsistent.

As for the proposed benefits...well, of all the things I've heard people say about package management over the years, this is the first time I've heard "I want to express version constraints in more, different places." Just my experience, yes, but hey, there it is. Nor do I expect tool use to be the minority case, or constraint expression to be a rare thing.

[John Souvestre]

Hi Sam.

 

> Hm, yes, I do think I missed part of your proposal - I didn't realize

 > you were suggesting that these file-level constraints be declared in

 > addition to a manifest file.

 

Right!  I'm saying that they would be used to populate the PM's config file, rather than a user doing it manually.

 

> Now, if you were suggesting they were *only* guides to be used by such

 > a stand-alone program for the purposes of building a manifest file, but

 > ignored when the solver works through, then...well, maybe I could be

 > convinced?

 

Pretty much, yes.  I would allow for manual overrides which might be necessary to resolve conflicts.  To be clear, I'm thinking that as each package is checked that the resolution algorithm is run on it.  Then later, when all packages have been processed, the project resolution would take place.

 

This allows any conflicts within a package to be identified and solved first.  Solving "localized" problems first seems logical.  Normally any such conflicts would show up only in your code and not in 3rd party imports.  Doing the individual package resolutions first, then the project resolution (as it is done currently) means that scaling is good.

 

> First, let's be clear: a file-level import restriction makes no sense in

 > Go. Files are not the level at which the compiler operates; packages are

 > the unit of compilation, and thus for compatibility checking.

 

I feel the opposite.  The import statements are distributed across the files which make up a package.  Then are not coalesced into a "package header" or some other common file.  The compiler coalesces them and then deals with them.  I'm not suggesting that this change.  I'm suggesting that the PM (packet manager) emulate the compiler by gathering its import info from the files rather than forcing a user to do it manually.

 

> As far as I can think, the benefits you're saying would arise from this

 > would be even greater if, say, we created a syntax that let you annotate

 > individual lines containing references to other packages with a constraint.

 

That is exactly what I am proposing.  The example (with 2 comments added) I gave was:

 

import (

    widget v1.2.3 - v1.2.*        <== Would require a change to Go

[OR]

    widget // +v1.2.3 - 1.2.*     <== Would not require a change to Go

)

 

Note:  I'm not suggesting change Go at this point.  I think that starting with the "add version info as a comment" form would be the way to start.  If it works out well, then perhaps.

 

> It tells us exactly where the need for the constraint arises from, and

 > tools could be taught to read it in all the same ways. Yes, it's more CPU

 > and a tad more I/O to do the additional parsing, but in a good design,

 > that's cacheable for deps, so that alone isn't enough of a reason not to

 > do it.

 

Yes!  But I don't see the need to cache.  As you analyze each set of files for a package, then resolve the package, you need only write the result to the PM's config (manifest) file.  You would want that stored just like it is now (resulting from user’s manual entry).  I guess you could also store a current timestamp so that you could reprocess only those which changed when running again later.

 

> But declaring constraints at the level of individual expressions, or ...

 

Not my proposal.  I'm only suggesting adding the version info to the individual imports, as per the example above.  The idea is to state the need for the import (as currently done) and any version limitations on it at the same time, in the same place.

 

> As for the proposed benefits...well, of all the things I've heard people

 > say about package management over the years, this is the first time I've

 > heard "I want to express version constraints in more, different places."

 

What I'm proposing is: I want to express (type in manually) a version constraint in only one place, the place that the constrained import appears.  And I don't want to have to manually examine every file in my project when setting up a PM's config file.  I expect that the PM will harvest my constraints, coalesce them per package, and place them into its config file for its use.

 

> Nor do I expect tool use to be the minority case, or constraint

 > expression to be a rare thing.

 

Then all the more reason to make it as simple (for the user), efficient (for the user), and accurate (reduce user oversights) as possible.  :)

[Sam Boyer]

I'm sorry, but I can't spend more time on this. You've missed significant parts of the counterargument I made, and generally don't seem to either see or care about the harmful complexity cost implications here. As Eric pointed out, I think you're mistaking simple for easy.

[Henrik Johansson]

What is even being discussed here? Changing the Go team release process to use SemVer? 

My suggestion is that we just try to copy Cargo form the Rust community. 

They have spent a lot of time to work out much of the kinks regarding this. 

Perhaps the Gb, Glide etc teams can work out the details or even settle on one of their respective tools to be that copy? 

I'm sure the internal Google teams can handle anything that comes out of this should this become the defacto community way of releasing packages. 

They have managed this for many years in the Java land with most if not all projects being Maven based or compatible. 

I really think we need a tool (1 tool) that "just works" and can build, package and release libraries in a more normal and expected way such as for example Cargo. One single tool would be better but if consensus can't be reached among those who knows this best then so be it of course. 

2¢

--
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.

[Sam Boyer]

On Saturday, July 23, 2016 at 8:57:12 AM UTC-4, Henrik Johansson wrote:

What is even being discussed here? Changing the Go team release process to use SemVer? 

No, we were discussing...

 

My suggestion is that we just try to copy Cargo form the Rust community. 

They have spent a lot of time to work out much of the kinks regarding this. 

...a specific aspect of how we might emulate something like Cargo.

 

Perhaps the Gb, Glide etc teams can work out the details or even settle on one of their respective tools to be that copy? 

Glide is already largely motivated by designs like Cargo. gps (https://github.com/sdboyer/gps) is the next step in that direction. And wycats is a fan https://twitter.com/wycats/status/755059275731308546 - this base is pretty well covered.

 

I'm sure the internal Google teams can handle anything that comes out of this should this become the defacto community way of releasing packages. 

They have managed this for many years in the Java land with most if not all projects being Maven based or compatible. 

The way that the language's versions are declared wasn't the focus of particular thread within the discussion. Rather, it was how and where any author of Go code declares their version constraints.

2¢

To unsubscribe from this group and stop receiving emails from it, send an email to go-package-management+unsub...@googlegroups.com.

[Henrik Johansson]

Ok cool, sorry if I came off harsh but it seemed like a bit of bikeshedding was going on.

I guess a library as a building block is very good but I still maintain that a common single tool would be better.

I think that while Cargo is a very thought through and well built tool the major thing about it (as well as for example npm) is that most if not all of the Rust

community is behind it. 

Personally I think the build/packaging tool is on the level of "go fmt", lets just have one that is good enough and build on that.

I realize that a lot of people have invested time in the current set of tools and I sympathize with all the feelings that go into that.

I do not however consider it a strong argument for settling for a library instead of a tool. 

Don't get me wrong, the library is an awesome start but if we end up with maven, maven2, maven3, gradle, sbt, buildr, gr8, ant, ivy, etc and these are just from the Java world then I would consider it a failure. It is of minor consequence if they all share the same base if we have to switch build system constantly and tool A chose to support some weird extra custom config making it impossible to work with using A. And it will happen.

We have already had a discussion about glide vs gb at work and we have just very recently started to use Go for real.

It will be a problem. Not an unsolvable problem but a little nagging one that just ads to the overall project specific issues of choosing technology and approaches 

when there are more than one person involved.

Normally I am for more freedom of choice for all developers but this is something I have felt so much although it has become easier of late when Maven dominated so clearly on the Java side.

The way I see it the workflow could be something like this:

go init .

.. change whatever you want maybe publish target server..

.. hack, hack ..

go package

go publish

I used "go" because it well _could be_ extended.

One of these steps could bump the version in some way or another command could be supplied for that.

Perhaps the SemVer analogies could be used instead of package/publish to major/minor/patch I don't know really.

It might not be obvious from the above rant but I am very happy that all of you are putting in this effort!

Extra 5¢.

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.

--

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.

[John Souvestre]

Correction: I did not realize that the prefix 'v' was dropped in the current SemVer spec 2.0.0. So please consider them gone from the examples I provided.

Also, SemVer doesn't allow for a name prefix at all. Below I used "go-". From what I gather, many do something similar but the choice of the delimiter varies. One person preferred '~' because it was not allowed in any part of a SemVer string, hence would be less ambiguous, hence easier to parse. I agree. So please consider the examples changed from "go-..." to "go~...".

John

John Souvestre - New Orleans LA

-----Original Message-----
From: jo...@souvestre.com [mailto:jo...@souvestre.com]
Sent: 2016 July 22, Fri 04:45
To: Go Package Management
Cc: jo...@souvestre.com
Subject: Re: [go-pm] Re: SemVer

On Thursday, July 21, 2016 at 8:47:23 AM UTC-5, Andrew Gerrand wrote:
> John, can you elaborate on what you mean by points 1, 2, and 3?

I believe that the strings don't exactly meet the SemVer 2 standard, and would need to be changed a bit.

Note: I don't believe that SemVer allows for a "prefix" field. It probably should, and I've seen others use "-" to delimit it. So that is what I'm showing below.

1) runtime.Version

"go1.6.3" ==> "go-v1.6.3".

The current function can alternately return a commit hash and build data.

Given this, and possible problems with backward compatibility, I'm thinking that the best solution might be to add a separate function: runtime.SemVer()

2) Go's filenames for releases.

"go1.6.src.tar.gz" ==> "go-v1.6.0+src.tar.gz"
"go1.7rc3.src.tar.gz" ==> "go-v1.7.0-rc3+src.tar.gz"

3) Build tags.

For a specific version: (not supported now) ==> "// +build go-v1.6.0"
For a range of versions: "// +build go1.6" ==> "// +build go-v1.6.0 - go-v1.7.0" (open, close)
Wildcards and other shortcuts: Not in the SemVer standard, but there are some in common usage, for example: "// +build go-v1.6.*"

[John Souvestre]

Hi Sam.

 

Thank you for the time you spent looking at my idea.

 

I'm sorry that I was not able to express it more clearly for you.

[jo...@souvestre.com]

(Sorry, I sent the original reply to you directly instead of to the list.)

Hi Eric.

 

 > Libraries should have a metadata file indicating dependencies just like

 > main programs, shouldn't they?

 

If they need one, fine.  But if an import line with a version tag will suffice, then why go to the extra trouble?

 

 > This seems like an argument for standardizing the package manager config file....

 

I'm all for this, regardless.  It's a more involved effort, so will probably take longer.

 

 > Most libraries will have multiple files, and they will want to centralize

 > their dependency constraints in one place.

 

I think the opposite.  Putting the dependency in the file which requires it seems more natural to me.

 

 > > Given equal results, the easiest path is the one he will prefer. :)

 

 > This strikes me as an argument about simple vs. easy:

 

No, I view it as both simpler and easier.  From the programmer's point of view, keeping related items (code requiring version dependency and version dependency statement limiting an import) in the same file is simpler and easier.

 

Put another way:  An import version dependency is file-level in scope.  Thus it should be stated in the file.

 

 > It may be easy to put version constraints on imports, but it feels to me

 > like it runs contrary to Go's aim to simplify.

 

Are you are against having version constraints on imports in general?  My idea was just to extend the current PM implementations a bit to make it easier, simpler, and more accurate.

 

Do we need version constraints on imports?  Not often, but yes, and more so as time passes (and more revised packages are authored).

[nos...@iandavis.com]

On Sun, Jul 24, 2016, at 04:46 PM, jo...@souvestre.com wrote:

Put another way:  An import version dependency is file-level in scope.  Thus it should be stated in the file.

If my application imports a dependency from 40 different source files do I have to have the same version comment on every import statement? Do I need to edit them all when one file requires a slightly newer version?

 

-- Ian

[John Souvestre]

Hi Ian.

 

Ø  If my application imports a dependency from 40 different source files do I have to have the same version comment on every import statement? Do I need to edit them all when one file requires a slightly newer version?

 

No.  I am proposing that you would include the version constraint as needed, per import.  This might vary depending on which package/file the import shows up in.  Most of the time you probably don’t care, so you would use the current release with a range allowing for patches (1.2.3 – 1.2.*) or allowing for additional features and patches (1.2.3 - 1.*).

 

Or, if it was a very, very often used import and you didn’t want to be bothered with the extra typing per import, you could always fall back to using the current method (hard-code it once in the PM’s manifest file).

 

I think that the individual constraints are safer, however.  Consider what happens if at some time in the future you decide to switch to 2.x.x of the import because you need a new feature or fix it offers.  As you fix the individual packages/files in your project to use the new API you would also update the version constraint in the file.  This way, if you overlook one, it will get caught automatically.

[John Souvestre]

P.S.

 

It also occurs to me that perhaps a PM could also offer an “init” or “update” versions command which would automatically enter the version constraints for you on the assumption that you want to use the set you are running with now.

[Sam Boyer]

On 7/23/16 20:00, Henrik Johansson wrote:
> Ok cool, sorry if I came off harsh but it seemed like a bit of
> bikeshedding was going on.

No worries, it can be hard to tell the difference.

>
> I guess a library as a building block is very good but I still maintain
> that a common single tool would be better.
> I think that while Cargo is a very thought through and well built tool
> the major thing about it (as well as for example npm) is that most if
> not all of the Rust
> community is behind it.
>
> Personally I think the build/packaging tool is on the level of "go fmt",
> lets just have one that is good enough and build on that.
> I realize that a lot of people have invested time in the current set of
> tools and I sympathize with all the feelings that go into that.
> I do not however consider it a strong argument for settling for a
> library instead of a tool.
>
> Don't get me wrong, the library is an awesome start but if we end up
> with maven, maven2, maven3, gradle, sbt, buildr, gr8, ant, ivy, etc and
> these are just from the Java world then I would consider it a failure.
> It is of minor consequence if they all share the same base if we have to
> switch build system constantly and tool A chose to support some weird
> extra custom config making it impossible to work with using A. And it
> will happen.

With respect to a library/the rationale for gps:
https://github.com/sdboyer/gps/wiki/Rationale

A library is a specific response to the divergent ecosystem we currently
have, with the goal of demonstrating underlying harmony. Yes, a library
could result in a profusion of multiple tools. I'm betting that,
counterintuitively, it gets us to a standard solution faster.

Most folks agree that something of "go fmt"-level ease would be great,
but "go fmt" isn't working on an NP-complete problem.

>
> We have already had a discussion about glide vs gb at work and we have
> just very recently started to use Go for real.
> It will be a problem. Not an unsolvable problem but a little nagging one
> that just ads to the overall project specific issues of choosing
> technology and approaches
> when there are more than one person involved.
>
> Normally I am for more freedom of choice for all developers but this is
> something I have felt so much although it has become easier of late when
> Maven dominated so clearly on the Java side.
>
> The way I see it the workflow could be something like this:
>
> go init .
> .. change whatever you want maybe publish target server..
> .. hack, hack ..
> go package
> go publish
>
> I used "go" because it well _could be_ extended.
> One of these steps could bump the version in some way or another command
> could be supplied for that.
>
> Perhaps the SemVer analogies could be used instead of package/publish to
> major/minor/patch I don't know really.
>
> It might not be obvious from the above rant but I am very happy that all
> of you are putting in this effort!

:)

Yeah, we'll have to see where a "publish"-like component fits in. To
have such a command more or less entails some kind of central registry,
which is something most folks want to avoid, at least for now.

Either way, though, I think we all want to arrive at something that's
more or less as straightforward as the pseudocommands you gave.

>
> Extra 5¢.
>
>
> lör 23 juli 2016 kl 23:30 skrev Sam Boyer <samuel....@gmail.com

> <mailto:samuel....@gmail.com>>:

>
>
>
> On Saturday, July 23, 2016 at 8:57:12 AM UTC-4, Henrik Johansson wrote:
>
>
> What is even being discussed here? Changing the Go team release
> process to use SemVer?
>
>
> No, we were discussing...
>
>
>
> My suggestion is that we just try to copy Cargo form the Rust
> community.
> They have spent a lot of time to work out much of the kinks
> regarding this.
>
>
> ...a specific aspect of how we might emulate something like Cargo.
>
>
>
> Perhaps the Gb, Glide etc teams can work out the details or even
> settle on one of their respective tools to be that copy?
>
>
> Glide is already largely motivated by designs like Cargo. gps
> (https://github.com/sdboyer/gps) is the next step in that direction.
> And wycats is a
> fan https://twitter.com/wycats/status/755059275731308546 - this base
> is pretty well covered.
>
>
>
> I'm sure the internal Google teams can handle anything that
> comes out of this should this become the defacto community way
> of releasing packages.
> They have managed this for many years in the Java land with most
> if not all projects being Maven based or compatible.
>
>
> The way that the language's versions are declared wasn't the focus
> of particular thread within the discussion. Rather, it was how and

> where /any/ author of Go code declares their version constraints.

> <mailto:go-package-manag...@googlegroups.com>.

> To post to this group, send email to
> go-package...@googlegroups.com

> <mailto:go-package...@googlegroups.com>.

[Sam Boyer]

~ is typically used in semver implementations to indicate a specific
type of range (see e.g. https://semver.npmjs.com/). It's also used by at
least a couple of the Go semver libs.

So, it probably wouldn't be great to use ~ as a delimiter in this
adjacent context.

[John Souvestre]

Would a range specification normally be used in the same context that the "name prefix" would be present? What character would you recommend?

[Andrew Gerrand]

On 22 July 2016 at 02:44, <jo...@souvestre.com> wrote:

On Thursday, July 21, 2016 at 8:47:23 AM UTC-5, Andrew Gerrand wrote:
> John, can you elaborate on what you mean by points 1, 2, and 3?

I believe that the strings don't exactly meet the SemVer 2 standard, and would need to be changed a bit.

Note: I don't believe that SemVer allows for a "prefix" field.  It probably should, and I've seen others use "-" to delimit it.  So that is what I'm showing below.

1) runtime.Version

"go1.6.3" ==> "go-v1.6.3".

The current function can alternately return a commit hash and build data.

Given this, and possible problems with backward compatibility, I'm thinking that the best solution might be to add a separate function: runtime.SemVer()

2) Go's filenames for releases.

"go1.6.src.tar.gz" ==> "go-v1.6.0+src.tar.gz"
"go1.7rc3.src.tar.gz"  ==> "go-v1.7.0-rc3+src.tar.gz"

The Go distribution itself is distinct in many ways to Go packages, so some special casing will be required in handling its version, and the existing versioning scheme is trivially mapped to SemVer. That being the case, I don't see a compelling reason to change the naming of our releases, which has been consistent since Go version 1 many years ago. (Others already rely on this consistency.)

 

3) Build tags.

For a specific version: (not supported now) ==> "// +build go-v1.6.0"
For a range of versions: "// +build go1.6" ==> "// +build go-v1.6.0 - go-v1.7.0" (open, close)
Wildcards and other shortcuts:  Not in the SemVer standard, but there are some in common usage, for example: "// +build go-v1.6.*"

It's not clear to me that supporting semver in build tags is desirable. It would add more complexity to what is already a fairly mysterious mechanism.

In summary, I argue that the Go distribution itself is a corner case and we shouldn't regard it as part of the general Go package versioning issue.

Andrew 

[Dave Cheney]

Seconded. For consistency it would be nice to harmonise build tags and the go release number with the recommended tagging scheme, but that would require boiling several independent oceans before we could achieve the core goal, which is dependency management for go code that exists outside the std lib. I think it's a reasonable compromise to consider the go distribution itself out of scope.

Dave

--

[Sam Boyer]

thirded, fwiw.

the main utility of semver is the a general set of semantics that can be
applied to a whole ecosystem. when work's already been done - as it has
for Go's existing release scheme - to establish other semantics, there
has to be compelling reason to change. and because, as dfc points out,
the problem we overwhelmingly care about is the public ecosystem, not
stdlib, that reason does not exist.

On 7/28/16 17:30, Dave Cheney wrote:
> Seconded. For consistency it would be nice to harmonise build tags and
> the go release number with the recommended tagging scheme, but that
> would require boiling several independent oceans before we could achieve
> the core goal, which is dependency management for go code that exists
> outside the std lib. I think it's a reasonable compromise to consider
> the go distribution itself out of scope.
>
> Dave
>
>
> On Fri, 29 Jul 2016, 07:15 'Andrew Gerrand' via Go Package Management
> <go-package...@googlegroups.com

> <mailto:go-package...@googlegroups.com>> wrote:
>
> On 22 July 2016 at 02:44, <jo...@souvestre.com

> <mailto:go-package-manag...@googlegroups.com>.

> To post to this group, send email to
> go-package...@googlegroups.com

> <mailto:go-package...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "Go Package Management" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/go-package-management/PyQte5OXvYs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> go-package-manag...@googlegroups.com
> <mailto:go-package-manag...@googlegroups.com>.

> To post to this group, send email to
> go-package...@googlegroups.com

> <mailto:go-package...@googlegroups.com>.

[John Souvestre]

Ø  In summary, I argue that the Go distribution itself is a corner case and

Ø  we shouldn't regard it as part of the general Go package versioning issue.

 

I accept this.  My original thought was that these changes would just have been a way for the Go Team to show support for the package versioning effort.  The consistency would have been nice, too, of course.  Perhaps later.  J

 

John

    John Souvestre - New Orleans LA

 

From: Andrew Gerrand [mailto:a...@google.com]
Sent: 2016 July 28, Thu 16:15
To: John Souvestre
Cc: Go Package Management
Subject: Re: [go-pm] Re: SemVer

 

 

 

On 22 July 2016 at 02:44, <jo...@souvestre.com> wrote: