Remove .NET version number from template.

[tmds]

This is consistent with the other '.NET' items in the OpenShift catalog, and the other devfiles which also don't include a version number.

@kadel ptal.

[openshift-ci]

Hi @tmds. Thanks for your PR.

I'm waiting for a devfile member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[johnmcollier]

/ok-to-test

[elsony]

This sample originates from the .Net 60 stack: https://registry.devfile.io/viewer/devfiles/Community+dotnet60
The .Net one is special and includes the version number as part of the name because it has multiple versions of the stacks in the devfile registry (see https://registry.devfile.io/viewer).

ODC currently only uses the samples for the public registry query since it currently supports the outer-loop function. The devfile 2.2 with outer-loop support will be GA very soon and the existing devfile stacks will start to support devfile 2.2 that ODC can consume. ODC will start moving to use the starter projects of the stacks instead of just using samples. By that time, you'll see multiple .Net entries with different versions of .Net samples from the registry. Therefore, having the .Net version as part of the name will be consistent with the future sample list. I would recommend keeping it as is.

[tmds]

Our experience is that providing samples for different version of .NET gives you a maintenance cost of keeping them in sync with the .NET life cycle (https://access.redhat.com/support/policy/updates/net-core).

The lowest maintenance cost comes from having a single sample that targets the latest LTS release.

You only need to update the sample when new LTS becomes available.
And, unlike a per-version sample, it doesn't go EOL.

[elsony]

Our experience is that providing samples for different version of .NET gives you a maintenance cost of keeping them in sync with the .NET life cycle (https://access.redhat.com/support/policy/updates/net-core).

The lowest maintenance cost comes from having a single sample that targets the latest LTS release.

You only need to update the sample when new LTS becomes available. And, unlike a per-version sample, it doesn't go EOL.

Adding @kadel to the discussion who provided different versions of the .Net stacks

[kadel]

This sample originates from the .Net 60 stack: https://registry.devfile.io/viewer/devfiles/Community+dotnet60
The .Net one is special and includes the version number as part of the name because it has multiple versions of the stacks in the devfile registry (see https://registry.devfile.io/viewer).

this was done like this because, at the time, there was no other way to have multiple versions of one stack.

The lowest maintenance cost comes from having a single sample that targets the latest LTS release.
You only need to update the sample when new LTS becomes available. And, unlike a per-version sample, it doesn't go EOL.

Adding @kadel to the discussion who provided different versions of the .Net stacks

We need to reduce maintenance costs, we are already struggling to keep Devfiles stacks up to date.
Keeping just one LTS version makes sense to me.

@elsony I'm not sure what our depreciation policy is regarding EOL products. .NET 5.0 reached End Of Life on May 2022 (devfile/api#964 could help with that)

We could simply copy dotnet6 to a new dotnet stack and use that stack as a main .net stack that will always be kept up-to-date with the latest .NET LTS.

[tmds]

The CI fail seems unrelated, it's about java-openliberty.
Is it a known issue? Can you re-trigger CI?

[tmds]

We could simply copy dotnet6 to a new dotnet stack and use that stack as a main .net stack that will always be kept up-to-date with the latest .NET LTS.

You should think about whether you want to make separate git repositories for these .NET versions, or separate branches in the same repository.
Our team does the latter. If you want to do the same, you should create a branch for the .NET 6 example, and add the branch name to the extraDevfileEntries.yaml file.

[kadel]

The CI fail seems unrelated, it's about java-openliberty.
Is it a known issue? Can you re-trigger CI?

There were some issues with the tests. If you rebase your PR with the current main branch it should fix it.

[elsony]

/retest

[elsony]

There were some issues with the tests. If you rebase your PR with the current main branch it should fix it.

@tmds Can you rebase this PR as requested? Also, you need to sign off the commits to fulfill the DCO requirements. See the details in the DCO failure for details.

[elsony]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: elsony, maysunfaisal, tmds

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [elsony]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment