process: preparing go1.18 support

[sio4]

Go version 1.18 was already released and many developers want to use the version with the Buffalo framework. Even though we think the current version of buffalo will work fine with the new go version, we need to make sure if there are some issues, also we need to officially announce the shifting of the supported version.

I am preparing for the transition with the following steps:

• process: preparing go1.18 support, step 1 - package level testing #2263
• integration test (as a part of cli testing)
• manual application-level test with a new sample application and/or an existing application
• updated go version of the builder Dockerfile cli#164
• fixed required checks of major repositories
• lastly, once all steps were successfully done, we need to announce the new supported version

Integration Test

This is a virtual step that covers the integration test. Since the cli package has many test cases for the integration tests, This step will not be executed as a separate action. This issue will be used to track if there are any issues with integration.

Manual Application-level Test

As the last step of "preparing go1.18 support", the application-level tests will be performed manually with new packages if any packages are upgraded as a part of this task. This issue will be used as a tracking issue if we found something not smooth.

[paganotoni]

@sio4 Should updates to Dockerfiles go here?

[sio4]

The first step was just finished without a big issue. the next step will be performed soon.

As a side note, the testing for the buffalo core was not successful when the new standard testing was applied since there was a hidden racing condition on the simple worker side, now the issue was fixed too. (Thank you for the standard testing workflow!)

[sio4]

@sio4 Should updates to Dockerfiles go here?

Ah, I will add the step! Missed during writing the OP.

[paganotoni]

Thank you. Appreciate it.

[sio4]

Step 3: manual application-level test with a new sample application and/or an existing application

• tested with a new app generated with the 0.18.5 version of CLI with go1.18.2
• tested with an existing app, fixed with 0.18.5 and with go1.18.2

All is good from the perspective of the go1.18 upgrade.

[sio4]

By the way, IMO, I would like to keep the code compatible with 1.16 for a while (I mean we don't need to proactively remove compatibility code) since I think there are many users who still using 1.16 in their production. (I hope our policy for the go version could be a kind of "we officially support the last two versions of go, but it could be ok using a few more previous versions") -- (copied from gobuffalo/cli#164 to keep track this here)

[paganotoni]

@sio4 I think we should keep our efforts as focused as possible given the amount of work we can afford as a team. Also, it's very hard to support a version of Go that's not even receiving updates by the Go team.

More than that, we know that running tests for another version of Go makes will consume more from our testing minutes in actions. I think we should stick to keeping support ONLY for the last two versions of Go.

That said, I love the improvements you've done with our actions, with those I think we're better prepared for the release of Go 1.19 (August 2022).

[sio4]

@paganotoni Yeah, I totally agree that we should focus on what we can do. Supporting older versions could not be a thing we can do continuously. However, what I wanted to say was not to keep our code to be compatible with the older versions but I think we don't need to deprecate them "proactively without a good reason". For example, supporting Generic could be a good reason (even though I am not a fan of Generic) since I guess that will be helpful to improve the performance in some parts, so once we move there, we should deprecate supporting 1.17 and below completely.

However, in my opinion, we also need to consider our users. I don't think the 6 months cycle (the same as go's release cycle) is good for the end-users because it can be a burden for them as the same as we are. (we cannot support older versions because of the limitation of resources, the users cannot chase the new versions because of the limitation of their resources) So my idea for the strategy is that "Rapidly move forward, only support the recent two versions officially, but deprecate lazily."

One more thing I want to say about this topic is that I hope we can just mark the current version of the buffalo core as v1 regardless of the original goal of v1, and declare v1 as the era until go1.17 so v1 supports go1.16 and go1.17. Then we could start preparing for the next era with go1.18 and above for the long-term goal while we use the period of go1.17 and go1.18 as the interim period of buffalo v2-alpha/beta.

Actually, the goal for the "road to v1" was mostly for the buffalo CLI and related stuff but not for the core, but now we already split them into two projects so we don't need to apply that single concept/strategy for those two in the same way.

So my rough idea is that:

• freeze the buffalo core as v1, make a v1 branch and just declare it as maintenance mode
  • v1 will be the legacy, it supports go1.16 and go 1.17.
  • v1 is in maintenance mode. there is no new feature or API change, only security fixes or critical bug fixes
• start preparing the v2 in the main branch of the core (if we deprecate the development branch as you told before)
  • v2 will be the next mainstream that supports go1.18 and above
  • the release target of v2 could be early 2023 or later
  • (I hope we can make a plan and milestone for this)
• the buffalo cli is just a tool. it is not a library so we don't need to tie it with the "supported version" concept
• supporting packages (like plush, helpers, genny,...) could not be in the main target. they can be flexible with their own features and status.

What do you think?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.