Re: Updating from Go 1.17 to 1.18

[Pier-Hugues Pellerin <ph@heykimo.com>]

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]

Hello,

I think it makes sense, looking at the number of impacted packages and from
my experience working
in go, even if the contract is the same, sometimes it does break on minor.

One more thing, should I do it in two patches like this?

1. Add go 1.18 inheriting from 1.17, allowing people to use 1.18 sooner?
2. Move to the default Go to 1.18 with (define-public go go-1.17) and
create the testing branch from that?

Thanks for the `refresh` tips.


On Sun, Apr 10, 2022 at 4:45 PM Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
>
> Pier-Hugues Pellerin <ph@heykimo.com> skribis:
>
> > I am trying to update Go to 1.18, I do have a *working* patch that
> defines
> > a package that inherits from 1.17 and that adjusts the inputs.
>
> Nice!
>
> > However, I have a few questions:
> >
> > 1. Is inheriting the way to do that? The package's build system appears
> to
> > be the same from 1.17.
> > 2. How can I rebuild dependents packages to ensure they are still
> building
> > correctly?
> > 3. Anything I should look into or test more for these kinds of packages?
>
> You can define Go 1.18 inheriting from 1.17; that’ll allow us to have
> both versions, and eventually we’ll remove the older one.
>
> Note that, to actually migrate Go packages to 1.18, you’ll need to
> additionally change this line:
>
>   (define-public go go-1.17)
>
> ‘guix refresh -l go@1.17’ shows the “contour” of the set of packages
> that currently depend on Go 1.17.  These are all the packages that need
> to be rebuilt if you change the line above.  Since that’s a lot of them,
> we could set up a dedicated branch and have it built by ci.guix.  We’d
> merge it once problems have been resolved.
>
> Does that make sense?
>
> Thanks,
> Ludo’.
>


-- 
ph,
http://heykimo.com

[-- Attachment #2: Type: text/html, Size: 2555 bytes --]