Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dropping legacy serialization support #174

Conversation

FreeAndNil
Copy link
Contributor

@FreeAndNil FreeAndNil commented Sep 5, 2024

Fixes #175

@FreeAndNil FreeAndNil changed the base branch from master to Feature/111-Dropping-support-for-older-runtimes September 5, 2024 23:00
@ppkarwasz
Copy link
Contributor

Could we just drop the ISerializable interface and SerializableAttribute altogether in 3.x for all runtimes?

Users that rely on that can use 2.x I guess.

@FreeAndNil FreeAndNil force-pushed the Feature/173-Dropping-legacy-serialization-support branch from 987c927 to 1dc9ca2 Compare September 9, 2024 09:01
@FreeAndNil FreeAndNil force-pushed the Feature/173-Dropping-legacy-serialization-support branch from 1dc9ca2 to bb60359 Compare September 9, 2024 09:04
@FreeAndNil FreeAndNil added this to the 3.0.0 milestone Sep 11, 2024
@FreeAndNil FreeAndNil marked this pull request as ready for review September 11, 2024 16:01
@FreeAndNil
Copy link
Contributor Author

Could we just drop the ISerializable interface and SerializableAttribute altogether in 3.x for all runtimes?

Users that rely on that can use 2.x I guess.
@ppkarwasz We would like to play safe as there was no feedback on #175.

@FreeAndNil FreeAndNil force-pushed the Feature/173-Dropping-legacy-serialization-support branch from 71da5e8 to 8327a6c Compare September 11, 2024 16:39
dotnet-version: 8
dotnet-quality: ga

- name: Build
Copy link
Contributor

@fluffynuts fluffynuts Sep 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggest: if you set up Node, you can do npm test to do all the build and test stuff you need via zarro. This way isn't wrong or anything, zarro is just more convenient, and will use the Quackers logger, which produces a useful final summary including failures and slow tests (and which works without zarro, but because of bugs in the dotnet test logger, you'll see some things twice - I've raised the issue so long ago that it's now been close because someone has started on a new logging framework for dotnet test, apparently).

For instance, we do something like this on our builds:

    - name: ⚙️ Setup .NET
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: ${{ matrix.dotnet-version }}

    - name: 🐢 Setup NodeJs
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'

    - name: 🏗️ Build and test 🧪
      env:
        DOTNET_SKIP_FIRST_TIME_EXPERIENCE: 1
        DOTNET_CLI_TELEMETRY_OPTOUT: 1
      run: |
        npm update -g npm --no-progress
        npm install --no-progress
        npm test

which runs all the tests with pretty, fully-namespaced output, and produces a summary like this:
image

as well as the list of slow tests and their timings above. What's considered slow? Default is any test taking more than 1s, but that can be guided by Quackers config (see: https://github.com/fluffynuts/quackers )

yes, quackers and zarro are more of my nonsense, so it's up to you. They are both currently installed - but I'd suggest updating them to latest

  • npm install --save-dev zarro@latest
  • either upgrade Quackers.TestLogger via your preferred mechanism or use zarro, with the environment variable UPGRADE_PACKAGES (which can accept regex values) and zarro upgrade-packages. I can help with this if you like. Although it's a little slow (waiting on nuget.org a lot), it's hella convenient, and how I keep several of our more volatile packages up to date in our work projects.

If you decide to keep on using zarro and need any assistance, please shout.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fluffynuts,

Feel free to modify the GitHub action. The current version is rather my attempt to understand how to build the project.

@FreeAndNil FreeAndNil merged commit 9d7c1cb into Feature/111-Dropping-support-for-older-runtimes Sep 12, 2024
@FreeAndNil FreeAndNil deleted the Feature/173-Dropping-legacy-serialization-support branch September 12, 2024 07:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants