Hello,

I've looked a bit more in detail on the Go package definition, Maybe we
should rethink how we are building the Go package in guix?
If I understand correctly, the current bootstrap chain is the following.

1.17 -> 1.16-> 1.4 which is the last gcc version of go.

Looking at the current proposal in Go
https://mail.google.com/mail/u/0/#inbox/KtbxLthKLdQNrjXvKllfQHQBQcKqVFdmPg
I don't think we will be able to remove 1.17 soon and also 1.4.  Because
they want to move to use 1.17 as the minimum
 version in the next minor.

We should probably also try to mimic how their bootstrap and have the
following:

   - Bootstrap 1.17 with 1.4
   - Bootstrap 1.18 with 1.4
   - Have 1.19 bootstrap with 1.17.

So maybe we should do something like this.

- Add go-1.18 build from 1.4.
- Add go-next that point to go-1.18
- Refactor 1.17 package definition that is shared between go-1.18. and
go-1.17.
- Move  go to go-1.18  in another branch
- Remove 1.16?

WDYT? I am not super familiar with the scheme but this seems like a good
exercise.

Thanks


On Wed, Apr 20, 2022 at 7:43 PM Pier-Hugues Pellerin <ph@heykimo.com> wrote:

> That sound great and great timing I was working on that as you send the
> mail
>
> I think also go-next is a good idea, I will split them in the following
> commits:
>
> 1. Add go-1.17 inherits from 1.18 (actually reversing the patch in the
> previous email)
> 2. Add go-next pointing to 1.18.
> 3. Make go point to 1.18.
>
> This will allow merging things right away to add support for go 1.18 and
> also allow Ludovic to create the branch and rebuild.
>
> Thanks
>
> On Wed, Apr 20, 2022 at 7:36 PM Katherine Cox-Buday <
> cox.katherine.e@gmail.com> wrote:
>
>> >>> Pier-Hugues Pellerin <ph@heykimo.com> writes:
>> >> Ludovic Courtès writes:
>>
>> >>> 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!
>>
>> Yes, thank you! I just found out I need this and came to see if anyone had
>> started on it.
>>
>> >> 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.
>>
>> I suggest inverting this: copy/paste go-1.17 to go-1.18, and then make
>> go-1.17
>> inherit from go-1.18. This means that when it's time to sunset a version,
>> it's
>> a simple delete and not something that cascades through all recent
>> versions.
>>
>> > 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.
>>
>> I was wondering if we don't want to start publishing a go-next package
>> like we do with emacs-next? That would allow us to publish the latest
>> version of Go without needing to immediately address building all the
>> packages that depend on it.
>>
>> Kindest regards,
>> --
>> Katherine
>>
>
>
> --
> ph,
> http://heykimo.com
>


-- 
ph,
http://heykimo.com