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 <thepudds1...@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 >>>>> >>>>> 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+unsubscr...@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 "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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
