(question) Why do you require `go 1.24.4` ?

[fogfish]

Your question

https://github.com/thomaspoignant/go-feature-flag/blob/main/go.mod#L3

It creates an issue for apps that uses your go module, requiring them to bump version.
A typical recommendation for Go lib development is keeping the lowest version. For the app development is opposite, you have to keep a highest version [1].

[1] https://www.reddit.com/r/golang/comments/15z63ct/should_you_always_try_to_be_on_the_latest_version/

[thomaspoignant]

Hello @fogfish

I understand your concerns and this is a valid point.
The main reason why I am on the latest version in because lower versions had CVEs.

Since the main usage of GO Feature Flag this days is through the relay proxy that we share via a binary or a docker image I wanted to be sure that I provide them without any CVEs.

I understand that it can be a bit disturbing for users of the go module.

What would be a better option for you? What were you expecting for version support?

[fogfish]

@thomaspoignant Thank you for addressing the question and making a cool solution.

As the context for you.
I am building a medium size aws serverless application using Golang only. The application requires (a) centralised configuration, (b) feature releasing and (c) A/B testing. As part of my investigation about "most" simple solutions but yet powerful solution, I've decide to adopting your library. (btw, It took me about 2 - 3h to bring and release first feature flag)

Due to serverless nature, I am not running any "servers", "instances", etc. The config is hosted at S3 and loaded by each Lambda function during the cold boot. Your solution is integrated into codebase as dependency.

I've raised the question due to my past challenges with mods & apps on the consensus of Golang version. As an example, in this particual case, the strict requirements for Go version has forced to make updates, updates into CI/CD, updates to dev environment, etc.

My recommendation would be a Hexagon architecture (this is what I am using as well). It isolates core domain from the way how domain is executed/operated. As you mentioned, the solution is shipped as binary, as docker by you. I am shipping the solution as lambda integrated, etc.

One possible option is creating cmd as own submodule that would ship the app and root would ship the lib. The app would follow the security standards and make patching regularly. The lib would leave own cycle patching version on necessity or forcing major release only. (e.g. I do have bunch of libs release with 1.22 but in app it was 1.24.3 before your change)

What do you think?

[thomaspoignant]

Hey, yes what you say makes a lot of sense and I have never followed that path because I wanted to release everything at once.

The main reasons were:

• CI is easier to build.
• Release process is easier to maintain.

I will keep this issue open and I will work on a different release process (probably using release-please).

[fogfish]

Thank you! Simplicity of the release is really lucrative. I am struggling same. Unfortunately, I do not have a silver bullet for you on this (my release frequency is not same, I can accommodate a bit of manual effort). I'll share my discovery if I find something to automate it.

[github-actions]

This issue has been automatically unassigned due to inactivity.

[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.