Infrastructure work items

sshnet / SSH.NET

SSH.NET is a Secure Shell (SSH) library for .NET, optimized for parallelism.

http://sshnet.github.io/SSH.NET/

MIT License

3.99k stars 931 forks source link

Infrastructure work items #1259

Open Rob-Hague opened 11 months ago

Rob-Hague commented 11 months ago

Let's discuss and coordinate ideas here to avoid crossing or unnecessary work. Feel free to add to (or remove from) the list.

[ ] Merge nuspec and AssemblyInfo into csproj #1256
[ ] Publish develop branch builds to appveyor nuget feed
[ ] Publish master branch builds to nuget.org and as github releases
[ ] Get code coverage from CI
- Either as an artifact from reportgenerator (my preference); or
- Use a codecov (or similar) service #1257
- (or both)

scott-xu commented 11 months ago

[x] Migrate the documentation from using sandcastle to docfx https://github.com/sshnet/SSH.NET/pull/1358 Relates to https://github.com/sshnet/SSH.NET/issues/1249
[ ] Integrate with Nerdbank.GitVersioning https://github.com/sshnet/SSH.NET/pull/1299
[x] Generate symbol package to support source link

jacobslusser commented 10 months ago

[ ] Drop support for net462 and netstandard2.0 (and maybe even netstarndard2.1)

There are code improvements I would like to make but are much more challenging to do when having to support these legacy runtimes/standards. Anyone who wishes to use those runtimes stays on the 2023.x version.

Rob-Hague commented 10 months ago

Long term that is the plan, but right now there is still plenty of scope for modernisation and bug fixes with the current targets. The library has only just dropped support for silverlight 😉

jacobslusser commented 10 months ago

I won't argue the point, but for me there is no harm in freezing those older runtimes at this version. If additional bug fixes or security items are found, then we simply support those on a releases/2023.x branch. I'm personally feeling the pain of these old frameworks as I work on "async all the way down" and modern logging implementations, both of which get significant enhancements in later versions of the runtimes and are requiring a lot of conditional compilation to make them work.

Please consider it, as I said, I don't see a downside to doing that, and it is directly impacting the modernization efforts.

P.S. - I'll only recently took an interest in contributing to this project, so you are free to ignore anything I say. :grin:

Rob-Hague commented 10 months ago

If additional bug fixes or security items are found, then we simply support those on a releases/2023.x branch

IMO this is too much effort on behalf of the (not even a) handful of contributors.

"Async all the way down" is already possible with the current targets (I have been thinking about it lately). A few conditional directives are no problem.

Sure, keeping these targets makes some shiny features prohibitive, but (IMHO) there is much more work that should take priority.

It will surely happen one day, but given the current position of the library, I do see the downsides and very few upsides.

You are of course free to modify your own fork as you please.

P.S. - I'll only recently took an interest in contributing to this project, so you are free to ignore anything I say. 😁

Your interest is welcome :) As I said, there is lots of work to choose from