Kind: release v0.6.0

[BenTheElder]

TODO:

• [x] Close out other issues in the milestone
• [ ] Write Release notes
  
  
  
  • [x] Write KUBECONFIG migration guide
  
  
  • [ ] Detail v1alpha4 config migration & features ...
  
  
  • [ ] ...
  
  
• [ ] tag / mark a release
• [x] push new images:
  
  
  
  • [x] v1.16.3 sha256:bced4bc71380b59873ea3917afe9fb35b00e174d22f50c7cab9188eac2b0fb88
  
  
  • [x] v1.15.6 sha256:1c8ceac6e6b48ea74cecae732e6ef108bc7864d8eca8d211d6efb58d6566c40a
  
  
  • [x] v1.14.9 sha256:00fb7d424076ed07c157eedaa3dd36bc478384c6d7635c5755746f151359320f
  
  
  • [x] v1.13.12 sha256:ad1dd06aca2b85601f882ba1df4fdc03d5a57b304652d0e81476580310ba6289
  
  
  • [x] v1.12.10 sha256:e93e70143f22856bd652f03da880bfc70902b736750f0a68e5e66d70de236e40
  
  
  • [x] v1.11.10 sha256:44e1023d3a42281c69c255958e09264b5ac787c20a7b95caf2d23f8d8f3746f2
  
  

I intend to finish this tomorrow ideally.

[tao12345666333]

:+1:

[tao12345666333]

• v1.16.3
• v1.15.6
• v1.14.9
• v1.13.12
• v1.12.10
• v1.11.10

Is these versions?

[BenTheElder]

yes, those versions.
I always do a fesh pull and check with git tag | grep v1.X locally when I go to build 😅
updated the issue body with those 🙃

[tao12345666333]

I wrote a script that I hope will make it easier for you to build. May also be useful for #197

(MoeLove) ➜  kind git:(master) for i in `seq 11 16`; do git ls-remote --tags https://github.com/kubernetes/kubernetes.git  "refs/tags/v1.$i.*" | sed -r 's!^.*refs/tags/v([0-9.]+)$!v\1!' | grep -v '\-[a-z]' | sort -ruV | head -n 1; done
v1.11.10
v1.12.10
v1.13.12
v1.14.9
v1.15.6
v1.16.3

[BenTheElder]

The trick for #197 is knowing when we should be building a new one. The answer for that is probably having prow kick it off when the tag is pushed.

I'm at kubecon now but will try to see about finishing this today. Didn't get to it over the weekend.

[tao12345666333]

The trick for #197 is knowing when we should be building a new one. The answer for that is probably having prow kick it off when the tag is pushed.

Yes, so it can be in the release process. :+1:

(I have not read the code of prow. Before this, I thought it would be fine to compare the difference between kubernetes's tag and DockerHub tags.

[BenTheElder]

let's discuss in #197 instead of here but .... that's not sufficient because you also need to consider the kind version. we need to consider how to communicate this to users as well.

in any case, building the images is also by far the easiest part. writing release notes takes time and care.

[BenTheElder]

$ git log v0.5.1.. --format="%aN <%aE>" --reverse | sort | uniq (note to self for the future)

[BenTheElder]

authors:

@amwat
@aojea
@aojea (another email)
@BenTheElder
@danderson
@mauilion
@dustinspecker
@fabiand
@beautytiger
@jbrette
@jieyu
@tao12345666333
@k8s-ci-robot
@lwr20
@maelvls
@luksa
@PatrickLang
@paol
@RafalKorepta
@robertojrojas
@sufuf3
@manics
@ysz
@cofyc
@sivanzcw 
@alejandrox1
@tanjunchen
@hwdef
@u5surf
@WalkerGriggs
@yuxiaobo96

really need to automated mapping that.

[tao12345666333]

I can do something for this. like https://github.com/containerd/release-tool

[BenTheElder]

https://github.com/kubernetes-sigs/kind/releases/tag/v0.6.0