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 > <javascript:>> 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 <javascript:>> >> 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 >>>>>> >>>>>> On Saturday, 15 September 2018 02:45:50 UTC+2, Sameer Ajmani wrote: >>>>>>> >>>>>>> Go modules can use the listed version or later minor versions. So if >>>>>>> B depends on v1.11 of A, then it can also work with v1.12 of A. >>>>>>> Therefore a >>>>>>> valid set of versions for the build is A v1.12 and B v1.3. >>>>>>> >>>>>>> On Mon, Sep 10, 2018 at 1:28 AM Scott Cotton <w...@iri-labs.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Well, ok. >>>>>>>> >>>>>>>> Did you mean if A v1.12 of a module depends on v1.3 of B which >>>>>>>> depends on v1.11 of A? >>>>>>>> >>>>>>>> So go modules don't actually necessarily depend on the listed >>>>>>>> dependencies? >>>>>>>> >>>>>>>> That is quite counteruintintive to me. >>>>>>>> >>>>>>>> It is much simpler in any case to use acyclic dependencies. >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> On 10 September 2018 at 04:25, Sameer Ajmani <sam...@golang.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I think there's a disconnection between how you and I understand >>>>>>>>> this system works. In a given build, there is only a single version >>>>>>>>> of a >>>>>>>>> module; there cannot be multiple copies, let alone many copies.So if >>>>>>>>> v1.11 >>>>>>>>> of module A depends on v1.3 of module B, which in turn depends on >>>>>>>>> v1.12 of >>>>>>>>> module A, then the build will choose A v1.12. The is only one version >>>>>>>>> of A >>>>>>>>> in the build. >>>>>>>>> >>>>>>>>> On Sun, Sep 9, 2018 at 1:40 PM Scott Cotton <w...@iri-labs.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Sameer, >>>>>>>>>> >>>>>>>>>> Thanks for asking, here are some thoughts, >>>>>>>>>> >>>>>>>>>> With time, this could create man many many copies of (different >>>>>>>>>> versions) of a module. >>>>>>>>>> this would slow down fetch, storage, compilation, etc potentially >>>>>>>>>> a lot, and it would only >>>>>>>>>> get worse and worse over time. >>>>>>>>>> >>>>>>>>>> if a security patch is applied to the most recent version in a >>>>>>>>>> version-compatible space of >>>>>>>>>> a module that depends on an earlier version of itself, then the >>>>>>>>>> security hole may still exist. >>>>>>>>>> Moreover, if the SCC of module dependencies is outside the >>>>>>>>>> control of the authors of the >>>>>>>>>> module being patched, it seems there is might be no way they >>>>>>>>>> could propagate the patch >>>>>>>>>> without editing history, which violates the very notion of >>>>>>>>>> versioning to begin with. >>>>>>>>>> >>>>>>>>>> The notion of software moving forward by versioning is in part an >>>>>>>>>> increase in reliability, >>>>>>>>>> not just security patches, so I would be frightened to use cyclic >>>>>>>>>> modules even in code >>>>>>>>>> for which I were certain there would be no security patches (like >>>>>>>>>> fixed memory, known cpu bounds >>>>>>>>>> math algorithms for example) >>>>>>>>>> >>>>>>>>>> Other than that, it is to me very confusing and counter-intuitive >>>>>>>>>> that a version of some software >>>>>>>>>> depend on a previous version of itself. Maybe I'm missing >>>>>>>>>> something in the modules >>>>>>>>>> specification or vision, and maybe, (even hopefully) I am wrong >>>>>>>>>> about these concerns. >>>>>>>>>> >>>>>>>>>> I could list more related ideas, but given that I might be wrong >>>>>>>>>> I'll leave it at that. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9 September 2018 at 19:19, Sameer Ajmani <sam...@golang.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> If a module depends on an earlier version itself, and successive >>>>>>>>>>> versions are backwards compatible, why is it not OK for the current >>>>>>>>>>> version >>>>>>>>>>> to satisfy that dependency? >>>>>>>>>>> >>>>>>>>>>> On Sun, Sep 9, 2018 at 1:13 PM Scott Cotton <w...@iri-labs.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Sameer, >>>>>>>>>>>> >>>>>>>>>>>> When I had a module self-dependency, I considered the fact that >>>>>>>>>>>> it worked a bug. I had not followed >>>>>>>>>>>> closely enough til this discussion to think of it as expected. >>>>>>>>>>>> >>>>>>>>>>>> As someone who has a tendency to often ask themself: "worse >>>>>>>>>>>> case how can this be a problem?" >>>>>>>>>>>> >>>>>>>>>>>> the list is indeed long and severe for modules which depend on >>>>>>>>>>>> themselves backwards in time. >>>>>>>>>>>> >>>>>>>>>>>> For cyclic dependencies which are somehow synchronised so that >>>>>>>>>>>> there is no backwards in time >>>>>>>>>>>> propagation, my impression would be "that's complicated", but I >>>>>>>>>>>> can't see offhand how it would be >>>>>>>>>>>> as problematic as backward in time self dependencies. >>>>>>>>>>>> >>>>>>>>>>>> Scott >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9 September 2018 at 18:38, Sameer Ajmani <sam...@golang.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> With respect to errors, I'm asking how things failed when you >>>>>>>>>>>>> had a cyclic module dependency. My expectation is that this >>>>>>>>>>>>> should just >>>>>>>>>>>>> work. If your module 0.12 has a dependency on itself with min >>>>>>>>>>>>> version 0.11, >>>>>>>>>>>>> then 0.12 satisfies that dependency (as long as it's following >>>>>>>>>>>>> the import >>>>>>>>>>>>> compatibility rule, which isn't necessarily expected for pre-1.0 >>>>>>>>>>>>> modules). >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Sep 9, 2018 at 9:10 AM Scott Cotton <w...@iri-labs.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Sameer, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't know what is considered an error and not an error >>>>>>>>>>>>>> with cyclic module dependencies. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Honestly, it makes my head hurt and simply requires too much >>>>>>>>>>>>>> thought that I'd rather spend on the code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For example, I don't want to think what will happen to some >>>>>>>>>>>>>> SCC in a module dependency graph after >>>>>>>>>>>>>> a decade of development, in particular if a module can depend >>>>>>>>>>>>>> on an earlier version of itself. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Scott >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9 September 2018 at 14:19, Sameer Ajmani < >>>>>>>>>>>>>> sam...@golang.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Are you seeing errors when there are cyclic module >>>>>>>>>>>>>>> dependencies? As I recall, cyclic dependencies between modules >>>>>>>>>>>>>>> (not >>>>>>>>>>>>>>> packages) must be allowed: >>>>>>>>>>>>>>> https://research.swtch.com/vgo-mvs >>>>>>>>>>>>>>> "Note that F 1.1 requires G 1.1, but G 1.1 also requires F >>>>>>>>>>>>>>> 1.1. Declaring this kind of cycle can be important when >>>>>>>>>>>>>>> singleton >>>>>>>>>>>>>>> functionality moves from one module to another. Our algorithms >>>>>>>>>>>>>>> must not >>>>>>>>>>>>>>> assume the module requirement graph is acyclic." >>>>>>>>>>>>>>> On Sun, Sep 9, 2018 at 7:58 AM Scott Cotton < >>>>>>>>>>>>>>> w...@iri-labs.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Paul, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9 September 2018 at 13:44, Paul Jolly <pa...@myitcv.io> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Scott, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > Should cyclic module dependencies be allowed? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, indeed in some situations they are totally necessary. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I wrote up an experience report on this very topic: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://gist.github.com/myitcv/79c3f12372e13b0cbbdf0411c8c46fd5 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Interesting. I'm not sure what cyclic module dependencies >>>>>>>>>>>>>>>> means. I do know some package managers (not go) boast of >>>>>>>>>>>>>>>> having a "solid >>>>>>>>>>>>>>>> transitive dependency model". I hope that any cycles in >>>>>>>>>>>>>>>> modules >>>>>>>>>>>>>>>> dependencies are either avoided or treated in a very clear >>>>>>>>>>>>>>>> simple way by >>>>>>>>>>>>>>>> go's modules. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > Should a module, following a cycle, be able to depend on >>>>>>>>>>>>>>>>> an earlier version of itself? (I saw this once...) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I can't see how this would work; indeed I can't even >>>>>>>>>>>>>>>>> unravel it in my >>>>>>>>>>>>>>>>> head! Do you have a concrete example to help explain? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Unfortunately, my concrete example is lost in sands of >>>>>>>>>>>>>>>> time, so I can only give a rough idea. I had cyclic module >>>>>>>>>>>>>>>> dependencies, >>>>>>>>>>>>>>>> somewhat unintended, but it crept in via some test case. I >>>>>>>>>>>>>>>> was playing >>>>>>>>>>>>>>>> with 111 or late 111 release candidate with it and asked it to >>>>>>>>>>>>>>>> rebuild >>>>>>>>>>>>>>>> go.mod at an untagged HEAD (I think) that was a few commits >>>>>>>>>>>>>>>> ahead of say >>>>>>>>>>>>>>>> v0.1.2. Then go.mod had that my module required v0.1.1 of >>>>>>>>>>>>>>>> itself in go.mod >>>>>>>>>>>>>>>> "indirectly". All I could figure out was that the module >>>>>>>>>>>>>>>> dependency cycle >>>>>>>>>>>>>>>> A -> B -> A had B depending on an older version of A via a >>>>>>>>>>>>>>>> test case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Scott >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Paul >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Scott Cotton >>>>>>>>>>>>>>>> President, IRI France SAS >>>>>>>>>>>>>>>> http://www.iri-labs.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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...@googlegroups.com. >>>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Scott Cotton >>>>>>>>>>>>>> President, IRI France SAS >>>>>>>>>>>>>> http://www.iri-labs.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Scott Cotton >>>>>>>>>>>> President, IRI France SAS >>>>>>>>>>>> http://www.iri-labs.com >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Scott Cotton >>>>>>>>>> President, IRI France SAS >>>>>>>>>> http://www.iri-labs.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Scott Cotton >>>>>>>> http://www.iri-labs.com >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "golang-nuts" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/golang-nuts/h2r8ktgOOZI/unsubscribe. >>>>> >>>> To unsubscribe from this group and all its topics, send an email to >>>>> golang-nuts...@googlegroups.com. >>>>> >>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Scott Cotton >>>> http://www.iri-labs.com >>>> >>>> >>>> -- >>> 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...@googlegroups.com <javascript:>. >>> 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 "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/h2r8ktgOOZI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Scott Cotton > http://www.iri-labs.com > > > -- 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.
