Castle.Core 6.0.0 proposed roadmap

[Romfos]

Infrastructure:

• Drop unsupported frameworks (Update TFMs and dependencies #696)
• Drop appveyor in favor of github actions (Drop AppVeyor in favor of GitHub Actions #700)
• Add .NET 10 to test matrix
• Support Sourcelink and Deterministic Build (Drop AppVeyor in favor of GitHub Actions #700)
• Migrate to slnx (Convert all solution files to .slnx format #716)

Codebase support work:

• Remove current [Obsolete] code from the codebase
• Drop serialization #ifdef from the code (Remove support for serialization? #562)
• Make minimal amount of #if preprocessor conditions to simplify codebase & future support
• Configure editorconfig & format codebase

Dependencies:

• Remove System.Diagnostics.EventLog dependency from the core package (Castle.Services.Logging.EventLogIntegration for Windows EventLog #694)

milestone:

• https://github.com/castleproject/Core/milestone/15

What else? please join to the discussion

cc @stakx @jonorossi

[stakx]

@Romfos: some more thoughts on the listed items. We'll probably have to continue discussing those items in their respective issues (where we have one), otherwise this issue might get hard to follow.

Drop appveyor in favor of github actions

Like I mentioned earlier, I'd prefer it too if this project used only one CI platform: GitHub Actions. Abandoning AppVeyor will require some coordination with @jonorossi – he will have to configure a NuGet API token in the GitHub settings in order for the NuGet publish to succeed. If he finds the time to do that short-term, then we can get started for the 6.0.0 release. However, he's often quite busy elsewhere these days, so it would be a pity to hold back the 6.0.0 release because of a mere build chain rework.

I therefore propose to release 6.0.0 first, in order to get any pending bugfixes & new features out the door... after that, when we have a little more time, we start on this.

Add .NET 10 to test matrix

No objections. Proceed if you'd like. Two things:

• I think we should start by adding .NET 9 test runs where they are currently still missing, since we're directly targeting that .NET version.
• Our builds have been getting quite slow. AppVeyor has been getting slower a few years ago, and we are running on two CI platforms (and thus have more builds to wait on). Perhaps we only start on this after we've abandoned AppVeyor to keep CI builds reasonably fast?

Support Sourcelink and Deterministic Build

No objections there. Proceed, if you'd like. Note that there have been two previous attempts at this: #524 and #669. Not sure why they were closed... third time's a charm, perhaps?

Migrate to slnx

Sounds good! Proceed, if you'd like.

Remove current [Obsolete] code from the codebase

If there were lots of [Obsolete] members I'd say, "why not?", but AFAIK there's really only one: IChangeProxyTarget.ChangeProxyTarget method. I don't see a pressing need to remove this, TBH.

Drop serialization #ifdef from the code

At least to me, it's not quite as straightforward as I first assumed... see my comments in #562 (comment).

Remove System.Diagnostics.EventLog dependency from the core package

Not sure how to proceed on this one as long as we haven't decided the fate of Castle.Core logging facilities. (See my comment in #694 (comment), too.)

EventLog has been moved out into a separate NuGet package starting in .NET 9, so once we add net9.0 to the list of targeted frameworks, we'll have to act. Until then I'd say let's wait a little longer.

Make minimal amount of #if preprocessor conditions to simplify codebase & future support

That would be nice, but I'm not sure it's feasible to further reduce FEATURE_* conditional compilation symbols without actually removing functionality, or resorting to the default NETx_y[_OR_GREATER] symbols (which would probably reduce clarity).

Configure editorconfig & format codebase

I agree that the codebase could use some modernization love, but IMHO it's not a huge priority. I'd especially like to avoid an automated rewrite that touches most code files and then obstructs Git blames. (I've made that mistake in the past. I've since learned that Git, or GitHub, can be set up to ignore specific commits in blames. Didn't to that back then, unfortunately.) Not a big priority IMHO.

[stakx]

See also the v6.0.0 milestone, which I'll attempt to keep in sync with the result of this discussion.