WARNING!

Before read the following proposal, you need to

understand April Fools' Day and its culture and
be torelant enough to get used to the culture
in addition, need to understood the fact: this issue is submitted in April 1st of submitter's date (JST)

Appreciated to your understanding, in advance.

Background

Over the years, multus project continues the development with several evolution into Kubernetes networking, keeping the its quality. Now is the good timing to leap beyond the current agile software development. I propose the transformation of multus development process beyond the current agile development.

Proposal

This transformation consists from following concepts:

Daily Software Release with Scalable Version Semantics
Provide Strict Version Compativility
Provide Strict Maintenance Version Policy with Upgrade Path

These are mandatory required for the transformation and none must be omitted.

Daily Software Release with Scalable Version Semantics

As noted above, multus main branch is very stable. Once build is failed, then immediate fix is commited to master branch. We do not keep the build broken more than 1 days 1. This means it is possible to release stable software release to every day. This is pretty agile and it must follow CI/CD pipeline concepts in Cloud Native. So we could release new multus every day as a stable, new version multus release. In this case, for ease of version number maintenance, let's provide new scalable version semantics as follows:

x.y.z

x: incremented in a year
y: incremented in a month
z: incremented in a day (if CI build is failed, it may be incremented)

This daily software release and scalable version semantics makes users estimate multus release cycle easily. For example, for new version, 5.0 will be released next year from 4.0 release and 5.0.1 will be released the next day from 5.0.0 release day.

Provide Strict Version Compativility

To make the multus release robust and make multus release consistent among the version, above version should be implemented in all components of multus, including:

Network-attachment-definition (introduce 'multusVersion' in net-attach-def CNI json config in net-attach-def)
Multus config files (each multus config introduces 'multusVersion' field and contains the multus version)
Communication Protcol (e.g. unix-socket between multus-thick and multus-shim)

These components must check each multus version and verify its consistency and must exit immediately if both version is not same.

Provide Strict Maintenance Version Policy with Upgrade Path

We also need to concern how many version should be actively maintained and how we provide upgrade path for each release. To optimize the effort and maximize its agility, we shoud maintain the last two versions (multus version released today and multus version released yesterday). Software upgrade path follows: it allows only upgrade from the last version. So '5.0' to '6.0', user need to upgrade 365 times (or 366 times). This may seem to be difficult to users to get used to, however, it is not actually difficult because it can be automated powered by several AI supported platform2: Chat GPT, Bard (need reference) and so on. Hence the user don''t have to concern.

Conclusion

This proposal introduces new multus development process to fit into (upcoming, maybe) new agile software development, featured by AI. I believe this brand-new cutting-edge super-duper agile software development process must provide users to mind-blowing experience (whatever good or bad).

k8snetworkplumbingwg / multus-cni

[AprilFool]Proposal of multus development process transformation to hyper agile software development process #1056