This message was deleted.
# k3s
a
This message was deleted.
h
Side question, I found #k3s-contributor, is that a better place for me to post these things?
c
nah here is fine
but I might also note that at the moment, that feature is available on all supported versions of K3s. 1.21 has been end of support since 1.24 came out.
h
Are you saying it was back-ported at the same time it came out? I just wanted to make it clear which version introduced the feature so people could easily identify why it might not be working in previous features.
c
no, just saying that it’s been available so long that there are no longer any supported versions where it doesn’t work
h
Yeah I was thinking there might be some people who have older versions, try it, it doesn’t work and they maybe file an issue. You can reject this though if you don’t think it’ll be a problem. I also just like to know myself what version features are introduced in ¯\_(ツ)_/¯
Should I just close this then? @creamy-pencil-82913
c
@nutritious-tomato-14686 is actually working on reorganizing the docs a bit, I think as part of that we might come out with a better convention for denoting what versions support what features
n
I am actually fine with this PR, I haven't yet decided/designed a better system to handle this yet.
I think your right Austin, when people on older versions see a feature in the docs and want to try it out, we should help them identify what minimum version they need to upgrade to.
c
our current backport policy makes that a bit more interesting, things are now likely to be added to 3 branches at once which is a lot of visual clutter for docs.
n
Yeah I kinda look at that as "the oldest version we support it", but that does leave gaps in the matrix, because we may introduce a feature in 1.22.9 and 1.23.2, but it wont be in 1.23.1, even though the docs say "Available as of 1.22.9+".
Saying "Available in 1.22.9+, 1.23.4+, 1.24.1+" is somewhat wordy, but is still short enough of a note IMO
h
One example I think of is the way the k8s docs do it with “FEATURE STATE”. Only somewhat applicable for k3s but maybe that’s a good starting point.
I think being explicit in the versions and backporting in general is very user friendly and helps save lots of people’s time on both sides.
I don’t work with GitHub almost at all so I don’t know if there’s a way to do any kind of like, badge linking on these pages that could do some kind of dynamicish update?
I’ve also never done any kind of automatic change log generation so I’m not sure what’s possible.
And I’m assuming there’s a reason the k3s/rke docs aren’t versioned in the same way the Rancher Server is, which is also a kind of way this could be handled.
This might be overkill but I like badges 😎
n
We don't use Github for generating/displaying the documentation (we are moving to docusaurus for k3s) so no badges 😞