[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: packaging go-ethereum, and ultimately bee (of ethswarm.org)
From: |
Sarah Morgensen |
Subject: |
Re: packaging go-ethereum, and ultimately bee (of ethswarm.org) |
Date: |
Wed, 01 Sep 2021 12:14:35 -0700 |
Hi,
Maxime Devos <maximedevos@telenet.be> writes:
>> > have uses outside go-ethereum, so they can be re-used as dependencies of
>> > new go packages, so over time, having to define many new packages when
>> > importing
>> > a go application should become less and less of a problem.
>> >
>> > (About version pinning: I'm ignoring version incompatibilities here. I
>> > don't know
>> > how much of a problem that is in practice ...)
>>
>> i'm not a go expert at all, but i think it's a rather frequent
>> situation in go land to move a dependency one git commit ahead, only
>> to pick up a bugfix that has just been pushed into its repo.
>
> ... unless you meant this here? But this seems to imply that version
> incompatibilities typically don't happen (otherwise just picking up
> a bugfix with a single commit doesn't seem plausible), so we can
> typically just use the latest version of the go module in guix, no?
A clarification: a canonical Go module version is supposed to follow
semantic versioning guidelines [0], so anything except a major version
bump is supposed to be backwards-compatible. This is further supported
by major version suffixes [1], which requires that "[s]tarting with
major version 2, module paths must have a major version suffix like /v2
that maches the major version. For example, if a module has the path
example.com/mod at v1.0.0, it must have the path example.com/mod/v2 at
version v2.0.0." Because each Guix package only represents one module
path, and that module path is used in the name of the package, we
*should* be able to update to (and use) any newer minor versions of a
module with no issues.
This doesn't address packages without any canonical versions, of
course...
[0] https://golang.org/ref/mod#versions
[1] https://golang.org/ref/mod#major-version-suffixes
--
Sarah
- Re: packaging go-ethereum, and ultimately bee (of ethswarm.org),
Sarah Morgensen <=