Hi Scott,
Great, it looks like you ran your own test too.
(We had both posted at approximately the same time a few minutes ago).
--thepudds
On Sunday, September 16, 2018 at 4:05:16 PM UTC-4, thepud...@gmail.com
wrote:
>
> 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> 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.
