Release cadence would be a factor here. .NET LTS releases are two years apart. As for a developer community willing to take up the task, I know I'm willing (based on how straightforward I found it to put together the POC). But I'm willing to wait if the community here wants to see more people than just myself step up. I'm pretty new here, so I'd rather work according to your processes rather than impose changes.
On Tue, Apr 20, 2021 at 11:42 AM David P Grove <gro...@us.ibm.com> wrote: > > > Matt Welke <mattwe...@gmail.com> wrote on 04/19/2021 09:52:00 PM: > > > > I've been spending some time with the .NET runtime lately, and I was > > informed in a GitHub issue discussion that we decided to skip the .NET > 5.0 > > release and wait for the next LTS version of .NET, which is .NET 6.0. > Shawn > > Black helpfully linked me to the mailing list archives which helped me > get > > up to speed with what was discussed officially before. > > > > I'd like to suggest we actually change direction and publish runtimes for > > each .NET release, including their "current" (non-LTS releases). I have a > > few reasons for this... > > Hi Matt, Welcome! > > My 2-cents is that we should be flexible on this point. What makes the > most sense really depends on the release cadence of the upstream language > runtime. > > For something like Node.js where there is a new LTS every year, bothering > with the interim non-LTS releases isn't worth the overhead of managing the > life cycles of the additional runtime kinds. > > If the .NET cadence is significantly slower and there is a developer > community that wants to take up the task, that seems fine in principle to > me. > > --dave > > > > > > 1) Many developers are okay taking on the risk of deploying applications > > using non-LTS software. Devs who have less to manage and are able to > > quickly update their apps fit into this category. Microsoft's own blog > post > > explaining their new versioning scheme even mentions that: > > > > "If you’re building a service and expect to continue updating it on a > > regular basis, then a .NET Core "Current" release like .NET 5.0 may be > your > > best option to stay up to date with the latest features .NET Core has to > > offer." ( > > INVALID URI REMOVED > > > > u=https-3A__devblogs.microsoft.com_dotnet_net-2Dcore-2Dreleases-2Dand-2Dsupport_&d=DwIFaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=Fe4FicGBU_20P2yihxV- > > > > apaNSFb6BSj6AlkptSF2gMk&m=itPvEFHpv_PtZeMj6K5SmD7p0tq5A4y9oqIS_0UnvAU&s=mpZ73ypN6ZYohQCLrWJvHyHrL0FH_lCVRqxImbHBGqI&e= > > > ) > > > > I think OpenWhisk users creating user functions fit into this category. > > They have control over the software they're creating and "expect to > > continue updating it on a regular basis." > > > > 2) There's also a situation where a developer likes to use LTS software > in > > production, but finds it challenging to migrate software two major > versions > > at a time. I fit into this category. I have a real world example at work > > where we had to upgrade through multiple major versions of Elasticsearch > at > > a time. We found it more approachable to upgrade one major version at a > > time, ensuring the software was running stable in production for each > major > > version update. It's probably the case that making an OpenWhisk user > > function is a lot less complex than running Elasticsearch, but I think > this > > philosophy still stands. If each .NET version had a runtime for > OpenWhisk, > > users could upgrade one version at a time if that works better for them. > > > > When thinking about potential problems, I was thinking about how this > might > > affect OpenWhisk operators, like IBM Cloud. They'd have an awkward > > situation where they'd either introduce a new runtime for a platform and > > then pull it out of service (because it would have reached EOL) before > > publishing the next version of the platform, or publish all runtimes for > > the platform, and warn users as strongly as they could that the non-LTS > > runtimes for the platform may be EOL despite being available to use, and > > should only be used for development and testing purposes (like my example > > with upgrading major versions one at a time). > > > > But I don't think that's even a big deal because what we're talking about > > here is what's available to all OpenWhisk operators and users. Operators > > can choose to not support non-LTS runtimes if that works better for them. > > > > I'm curious to hear everyone's thoughts on this. If time is an issue, I > > should mention that I already have a POC of a .NET 5 runtime working. I > > tested it on IBM Cloud as a Docker runtime. I can lend my time to > polishing > > it up for release and helping with the release process if someone is > > willing to show me the ropes. :) > > > > Thanks, > > Matt >
