Hi Scott,
Regarding your question about pre-release tags and 'go get -u', my
understanding is that when the documentation says:
'The -u flag instructs get to update dependencies to use newer minor or
patch releases when available.'
...the use of the phrase 'newer minor or patch release' is exclusive of
prelease tags (e.g., 'v1.2.3-alpha1').
My understanding here is based on the documentation, what I've read
elsewhere, and my experience so far.
There are some similar sentiments expressed elsewhere in the documentation,
such as in the "Module-aware go get" section:
'For each named package or package pattern, get must decide which
version of the corresponding module to use. By default, get chooses the
latest tagged release version, such as v0.4.5 or v1.2.3. If there are no
tagged release versions, get chooses the latest tagged prerelease version,
such as v0.0.1-pre1. If there are no tagged versions at all, get chooses
the latest known commit.'
Or in the "Module queries" section:
'All queries prefer release versions to pre-release versions. For
example, "<v1.2.3" will prefer to return "v1.2.2" instead of "v1.2.3-pre1",
even though "v1.2.3-pre1" is nearer to the comparison target.'
All that said, as I mentioned before, I think we are all still learning...
--thepudds
On Sunday, September 16, 2018 at 12:33:17 PM UTC-4, Scott Cotton wrote:
>
> Thanks again @thepudds for the helpful info.
>
> with module aware go get -u at tip on golang.org, it says
> """
> The -u flag instructs get to update dependencies to use newer minor or
> patch releases when available. Continuing the previous example, 'go get -u
> A' will use the latest A with B v1.3.1 (not B v1.2.3).
> """
>
> For example, if I have a requirements for M vQ.R.S and the latest
> available minor or patch release is
> M vQ.R.{S+1}-alpha.1, with nothing else after vQ.R.S available.
>
> Then does go get -u in module aware mode update to the alpha? If so,
> should it? (I would think not,
> but reading the docs I would think it would update to the alpha)
>
> Scott
>
> On 16 September 2018 at 16:44, <thepud...@gmail.com <javascript:>> wrote:
>
>> Hi Scott,
>>
>> Modules do provide support for semver pre-release notation. You can read
>> more about it in these sections of the documentation, for example:
>>
>> https://tip.golang.org/cmd/go/#hdr-Module_queries
>> https://tip.golang.org/cmd/go/#hdr-Pseudo_versions
>> https://tip.golang.org/cmd/go/#hdr-Module_aware_go_get
>>
>> --thepudds
>>
>> On Sunday, September 16, 2018 at 10:31:43 AM UTC-4, Scott Cotton wrote:
>>>
>>> Thanks Sameer,
>>>
>>> I have a question about semver and modules, perhaps it was already
>>> answered somewhere, but if so I don't know where.
>>>
>>> The question is: semver.org allows for pre-release notation, the
>>> document below does not mention pre-release.
>>> To some extent Go uses pre-releases.
>>>
>>> I, for one, find the idea useful and would like to use pre-release info
>>> with modules.
>>>
>>> So can anyone comment, inform, or provide a pointer to some
>>> documentation about pre-releases as they relate to modules?
>>>
>>> Best,
>>> Scott
>>>
>>> On 15 September 2018 at 22:11, Sameer Ajmani <sam...@golang.org> wrote:
>>>
>>>> Thanks. The relationship between semantic versioning and Go packages is
>>>> described in detail here: https://research.swtch.com/vgo-import
>>>> On Sat, Sep 15, 2018 at 3:52 PM <thepud...@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> One additional set of brief comments.
>>>>>
>>>>> This was a fairly nuanced and long thread, and I'm pretty sure I did
>>>>> not follow all of it, but I think a question related to the conversation
>>>>> here is -- what does 'require foo v1.1.1' really mean?
>>>>>
>>>>> Perhaps one way to think about that usage of the verb 'require' is
>>>>> that it really needs to be read in the context of semantic versioning (
>>>>> https://semver.org).
>>>>>
>>>>> If something states it requires v1.1.1 of foo, in the context of
>>>>> semantic versioning that really means that particular requirement for
>>>>> v1.1.1 would be satisfied by foo >= v1.1.1 and < v2, given semver defines
>>>>> versions in that interval to be valid and backwards compatible
>>>>> substitutions for v1.1.1 (and anything v2 or higher is considered
>>>>> incompatible with any v1 version).
>>>>>
>>>>> And a variation of that first question is -- what does it mean for a
>>>>> build if you have both a 'require foo v1.1.1' and a 'require foo v1.2.2'?
>>>>>
>>>>> One initial guess might be that the build ends up with two copies of
>>>>> foo (v1.1.1 and v1.2.2) given there are two 'require' statements with
>>>>> those
>>>>> two different versions. That is a reasonable guess, but not actually what
>>>>> happens.
>>>>>
>>>>> If you instead read that verb 'require' in the context of semantic
>>>>> versioning, it means that if the build instead picks a _single_ copy of
>>>>> foo
>>>>> at version v1.2.2, that actually would satisfy _both_ of the requirements
>>>>> for v1.1.1 and v1.2.2 (given v1.2.2 is defined by semver to be a
>>>>> backwards
>>>>> compatible substitution for v1.1.1). And of course, this is what the go
>>>>> build system actually would do in this scenario.
>>>>>
>>>>> Said another way, when you use modules, the go command _mandates_ that
>>>>> modules use semantic versioning and expects that the versions accurately
>>>>> describe compatibility: it assumes that v1.2.2 is a backwards compatible
>>>>> replacement for v1.1.1, and hence v1.2.2 is a valid answer if you have
>>>>> both
>>>>> 'require foo v1.1.1' and a 'require foo v1.2.2'.
>>>>>
>>>>> In any event, this is all still fairly new, and everyone is still
>>>>> learning about the overall system. (The broader community is of course
>>>>> learning about the new system, but even the people who implemented this
>>>>> system are in a learning phase, including because they are learning about
>>>>> how the community will use the new system).
>>>>>
>>>>> --thepudds
>>>>>
>>>>> On Saturday, September 15, 2018 at 1:11:49 PM UTC-4, Scott Cotton
>>>>> wrote:
>>>>>>
>>>>>> Thanks! Very useful.
>>>>>>
>>>>>> +1 for aliasing "go mod list" to "go list -m"
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 15 September 2018 at 18:59, <thepud...@gmail.com> wrote:
>>>>>>
>>>>> > "Maybe having a way for "go mod" to output what is used would be
>>>>>>> less confusing?"
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> To see a list of the selected module versions, one way is to use use
>>>>>>> 'go list -m all'. This shows the actual versions used based on all of
>>>>>>> the
>>>>>>> various requirements in a build. Sample output:
>>>>>>>
>>>>>>> $ go list -m all
>>>>>>> example.com/my/module
>>>>>>> github.com/aws/aws-sdk-go v1.15.35
>>>>>>> github.com/go-ini/ini v1.25.4
>>>>>>>
>>>>>>> Another other useful tool is for inspecting requirements is 'go mod
>>>>>>> graph' (which prints the module requirement graph), and if you are
>>>>>>> curious
>>>>>>> why a particular module is showing up in your go.mod, you can run 'go
>>>>>>> mod
>>>>>>> why -m <module>' to answer that question.
>>>>>>>
>>>>>>> You can read some more about these here:
>>>>>>>
>>>>>>>
>>>>>>> https://tip.golang.org/cmd/go/#hdr-The_main_module_and_the_build_list
>>>>>>>
>>>>>>> https://tip.golang.org/cmd/go/#hdr-Explain_why_packages_or_modules_are_needed
>>>>>>> https://tip.golang.org/cmd/go/#hdr-Print_module_requirement_graph
>>>>>>>
>>>>>>> The first link above also provides a short description of the build
>>>>>>> list, which is related to several of the questions raised in this
>>>>>>> thread:
>>>>>>>
>>>>>>> ----------------
>>>>>>> "The set of modules providing packages to builds is called the
>>>>>>> "build list". The build list initially contains only the main module.
>>>>>>> Then
>>>>>>> the go command adds to the list the exact module versions required by
>>>>>>> modules already on the list, recursively, until there is nothing left
>>>>>>> to
>>>>>>> add to the list. If multiple versions of a particular module are added
>>>>>>> to
>>>>>>> the list, then at the end only the latest version (according to
>>>>>>> semantic
>>>>>>> version ordering) is kept for use in the build."
>>>>>>> ----------------
>>>>>>>
>>>>>>> --thepudds
>>>>>>>
>>>>>>> On Saturday, September 15, 2018 at 6:34:55 AM UTC-4, Scott Cotton
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Thanks for the clarification.
>>>>>>>>
>>>>>>>> Maybe having a way for "go mod" to output what is used would be
>>>>>>>> less confusing? I would have found so at least.
>>>>>>>>
>>>>>>>> Cycles crossing major versions may be more problematic.
>>>>>>>>
>>>>>>>> similarly in the case of coordinating a collection of modules,
>>>>>>>> dependency cycles may lead unintentionally to different used versions
>>>>>>>> depending on the build context. While the potential use of
>>>>>>>> multiple versions is a useful feature of modules, I am not convinced
>>>>>>>> that in this context it is desirable. Also, if cycles can span
>>>>>>>> arbitrarily large sets of uncoordinated modules, then it seems to me
>>>>>>>> that
>>>>>>>> is not the intended use case for cycles and that might be
>>>>>>>> undesirable or even lead to the inability of a module maintainer in
>>>>>>>> the
>>>>>>>> cycle
>>>>>>>> to effectively propagate an update.
>>>>>>>>
>>>>>>>> If I come across anything more concrete, I'll file an issue. Just
>>>>>>>> food for thought at this point.
>>>>>>>>
>>>>>>>> Best
>>>>>>>> Scott
>>>>>>>>
>>>>>>>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
