Closed irfanurrehman closed 6 years ago
fejta-bot
commented
6 years ago Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
fejta-bot
commented
6 years ago Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten /remove-lifecycle stale
This issue is to pick up some debate/pointers from folks with more experience in k8s and its maintenance about the probable release versioning that is ideal for projects which have been separated out into their own github repos with the intention of independent maintenance and release. As the project until now was maintained and released as part of k8s releases, there are 2 alternatives to use:
Both have some pros and cons and there is no clear precedent. We have an example of client-go, which maintains its own versioning scheme and publishes a compatibility matrix (probably not a very good example as its only a library for clients). We also have an example of tools like kubeadm and kubectl (which probably are candidates which will be maintained externally) but haven't reached there yet and the code and binaries still map to k8s core. It makes lot of sense to follow some scheme which by version itself can provide enough info to the reader about its compatibility with any given k8s release.
I initiated a brief doc a while ago to collect comments. This issue is an attempt to share that will a wider audience and/or to collect feedback/suggestions for the same here. Please point me in the right direction if this is not the place for this topic.
cc @kubernetes/sig-multicluster-misc