Feature Request - Support for .NET Core 2.2 and 3.x?

[natiki]

Hi,

I was wondering if there were plans for .NET Core 2.2 and the imminent .NET Core 3.x?

[andresmgot]

Pinging @allantargino as the maintainer but we are open to contributions here!

[allantargino]

Hi @natiki Currently the .NET Core 2.1 is the main one just because it is the official LTM (long term support). We can try to support both (specially if there is any business case around new features in https://docs.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-2.2?view=aspnetcore-2.2).

It should be easy to keep up with all versions, but we need to plan how to support all older versions.

For 3.x, since it is still in preview now, I would prioritize 2.2 - but as @andresmgot said, we are open to contributions :)

[andresmgot]

Just my two cents, I would avoid using alpine for things like:

https://www.bleepingcomputer.com/news/security/bug-in-alpine-linux-docker-image-leaves-root-account-unlocked/

We were using alpine for some images and we decided to move away from it. Just a recommendation but we use bitnami/minideb that is also a minimal image but using Debian instead (and you can use apt as well if needed).

[natiki]

Hi,

The way I see things is that "we do" 2.2 and use that as the vehicle to bring down the image size. Ultimately I am happy to go with bitnami/minikube or anything else for that matter as long as we focus on getting the image size down.

I am happy to tackle doing 2,2 along these lines as long as both of you are happy to put up with heaps of questions ;-) as I am a total noob for some of the tech used in kubeless.

@andresmgot is there any chance of placing 2.2 onto the kubless docker repo as previously discussed? I can do the same as @allantargino and spin up my own repo but ultimately it would be best if 2.2 was done where @allantargino and optionally myself were repo owners. That will keep the fracturing to a minimum long term.

Once I have figured out 2.2 then 3.x can be done with minimal effort I am assuming. 3.x can stay as experimental until its release. The reason for the push to 3.x although it is still in preview is that we are already gearing up some new deliverables based on 3.x being available in Sept as per M$ current roadmap.

At that point 2.1, 2.2, 3.x can be maintained and upgraded side by side. And then when .NET 5 surfaces we do that as well. ie Leave 2.1 alone as it works and focus on the rest.

Thoughts?

[andresmgot]

Hi,

Yes, you can do as many questions as you want :) (I can answer the ones related to Kubeless)

@andresmgot is there any chance of placing 2.2 onto the kubless docker repo as previously discussed? I can do the same as @allantargino and spin up my own repo but ultimately it would be best if 2.2 was done where @allantargino and optionally myself were repo owners. That will keep the fracturing to a minimum long term.

You can use your personal repo in the meantime, later one I can manually copy images to the kubeless registry if needed.