Proposal to merge `images/nginx-1.25` into `images/nginx` and remove redundancy about ingress-nginx

[longwuyuan]

The project supports controller with v1.25 and also another series with v1.21

[blaisewang]

The project supports controller with v1.25 and also another series with v1.21

Thank you for your response. I would like to know if there are any documents or records indicating that starting from v1.10.0, the project plans to support multiple Nginx versions. This information would be greatly helpful for understanding the new direction and adjusting our internal processes accordingly.

[longwuyuan]

Its implied because project will support v1.9.x

[blaisewang]

Its implied because project will support v1.9.x

Just to clarify, do you mean that even after the release of v1.10.0, there will still be a v1.19.7 released that is based on Nginx 1.21.x? I'm trying to understand the versioning strategy and how these parallel releases align with each other.

[longwuyuan]

Its driver by absolute practical requirement first.
And then the circumstances and feedback influence decisions.

For example all users can not be forced to move to v1.10.x so a future fix may well result into a v1.9.7.

For example, once a v1.11.X is out, the project will have option to evaluate stopping support for v1.9.X .

The already published bits will continue to be available for download though (just to state the obvious).

Relevance being your proposal could be feasible in future after v1.11 or v1.12 is out. (if it improves the project for tons of users)

[blaisewang]

Thank you for your explanation. While I understand the release strategy, I believe it might be more logical to maintain the same directory structure and use branches release-1.9 and release-1.10 to track the releases of different versions separately. This approach could potentially simplify the project structure and make it easier for users to follow and integrate with their existing workflows.

[strongjz]

/assign @rikatz

I agree this should be cleaned up. We can bump it directly on the 1.9 branch if we need to rebuild nginx.

[strongjz]

/priority backlog
/triage accepted

[blaisewang]

@strongjz Thank you for accepting the proposal. If it's possible, I would be glad to take the cleanup work.

[strongjz]

While we support both 1.9 and 1.10, which use 1.21 and 1.25, we need to keep both directories for the time being. It will be cleaned up in the future.

/close

[k8s-ci-robot]

@strongjz: Closing this issue.

In response to this:

While we support both 1.9 and 1.10, which use 1.21 and 1.25, we need to keep both directories for the time being. It will be cleaned up in the future.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.