Release v32.2.2

[AdyenAutomationBot]

Merged pull requests to be released:

• chore(config): migrate Renovate config #1205

Full Changelog: v32.2.1...main

[gemini-code-assist]

Summary of Changes

Hello @AdyenAutomationBot, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request serves as a release preparation, updating the Adyen .NET API library to version "32.2.2". It primarily involves incrementing the version numbers in various project files and internal constants to reflect the latest state of the codebase, incorporating changes from previously merged pull requests.

Highlights

• Version Update: The library's version has been incremented from "32.2.1" to "32.2.2" across all relevant project configuration files and internal constants.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the version number to 32.2.2 across several files. While the changes are consistent, they highlight a maintainability issue: the version number is duplicated in multiple locations (.csproj files, a C# constant, and a VERSION file). This manual process is error-prone and can lead to inconsistencies. My review includes suggestions to centralize the version management by leveraging MSBuild properties to remove redundant version declarations in the project files, reading the version from assembly attributes instead of using a hardcoded constant, and automating the generation of the VERSION file. These changes would make the release process more robust and less manual.

[gemini-code-assist]

To simplify version management and reduce redundancy, you can rely on the Version property. AssemblyVersion, FileVersion, and PackageVersion all default to the value of Version if not specified. You can remove the explicit declarations for AssemblyVersion, FileVersion, and PackageVersion.

    <Version>32.2.2</Version>

[gemini-code-assist]

The AssemblyVersion and FileVersion properties default to the value of the Version property if they are not specified. Since they are all being set to the same value, you can remove these two lines to reduce redundancy and simplify version management.

[gemini-code-assist]

Using the version number as a package tag is unconventional. PackageTags are meant for keywords that help users discover your package on NuGet, while the version is already a primary property of the package. Consider using descriptive tags like adyen, payment, fintech, pos, terminal instead. If the version number is required here for some internal process, consider automating its update from a single source of truth to avoid manual errors.

[gemini-code-assist]

The PackageVersion property also defaults to the value of the Version property. You can remove this line to avoid duplication and simplify version management.

[gemini-code-assist]

This hardcoded version string is another place where the version number is duplicated across the codebase. This increases the risk of inconsistencies during a release. To ensure this value is always in sync with the project version, consider reading it from the assembly's metadata at runtime.

For example, you could change this const to a static property:

using System.Reflection;
// ...
public static string LibVersion { get; } = typeof(ClientConfig).Assembly.GetCustomAttribute<System.Reflection.AssemblyInformationalVersionAttribute>()?.InformationalVersion;

This would centralize your versioning and make releases less error-prone.

[gemini-code-assist]

Having a separate VERSION file that is manually updated adds another step to the release process and can lead to version mismatches. To improve maintainability, consider generating this file as part of your build or release pipeline, sourcing the version from a single, centralized definition (like the one in the main .csproj file).