chore(examples): update versions in discounted-asset-trade example

[rajat-dlt]

This updates the versions in the discounted-asset-trade example to ensure
compatibility and proper functionality.

The Fabric version was upgraded from 2.4.4 to 2.5.6 as the internal image
being used required v2_5 capability.

Additionally, as per the Hyperledger Fabric documentation
(https://hyperledger-fabric.readthedocs.io/en/release-2.5/prereqs.html),
Go version 1.22.4 is needed for the example to work in its entirety.

Signed-off-by: Rajat Sharma [email protected]

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[petermetz]

@rajat-dlt

Commits that have the type of fix will appear in the release notes (later when we cut the release) as production bug fixes. This commit does not appear to be fixing a production bug.

The important thing is that the release notes that we generated from the commit messages will provide a useful source of information to the reader.

For example: For someone who is considering upgrading their existing Cacti deployment that they are running in production, it does not matter if we fixed a failing test case because it does not have any material effect on their potential upgrade and therefore including test case fixes in the release notes of new releases is cluttering and distracting people from the important fixes and new features.

• Therefore, please rewrite the commit message based on the guide below.
• Please also make sure to sync the commit message with the pull request description.
• Please also make sure to sync the commit subject line (the first line) with the pull request title.

Guide to Writing Good Commit Messages with Conventional Commits

Commit messages are an essential part of maintaining a project's history. Good commit messages help team members understand the context and purpose of changes. The Conventional Commits specification provides a standard for commit messages that makes this process more efficient and consistent.
Conventional Commits Format

The Conventional Commits specification outlines a format for commit messages that is structured and informative. Here is the basic format:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Components of a Commit Message

1. Type: A keyword indicating the type of change.
2. Scope: A noun describing the section of the codebase affected (optional but recommended).
3. Description: A brief summary of the change.
4. Body: A more detailed explanation of the change (optional).
5. Footer(s): Information about breaking changes or issues this commit closes (optional).

Common Types

• feat: A new feature for the user.
• fix: A bug fix (reserved for production bug-fixes only).
• docs: Documentation changes.
• style: Code style changes (e.g., formatting, missing semicolons).
• refactor: Code changes that neither fix a bug nor add a feature.
• perf: Changes that improve performance.
• test: Adding or correcting tests.
• chore: Changes to the build process or auxiliary tools and libraries such as documentation generation.

Example Commit Messages

Adding a New Feature

feat(parser): add ability to parse arrays

Fixing a Bug

fix(api): ensure correct response format

Updating Documentation

docs(readme): update installation instructions

Style Changes

style(button): remove unnecessary margin

Code Refactoring

refactor(user-service): extract user validation logic

Performance Improvement

perf(database): optimize query performance

Adding Tests

test(auth): add unit tests for login functionality

Miscellaneous Chores

chore(deps): update dependency versions

Special Considerations for fix

Reserved for Production Bug-Fixes

The fix type should only be used for production bug fixes. If you're correcting or repairing documentation, tutorials, examples, or test cases, do not use fix. Instead, use docs for documentation, test for test cases, and chore for other non-code changes.

Examples of Incorrect Usage of fix

Incorrect

fix(readme): correct spelling mistake

Correct

docs(readme): correct spelling mistake

Incorrect

fix(test): repair broken test case

Correct

test(unit): repair broken test case

Writing a Good Commit Message

1. Be Descriptive: Your commit message should clearly describe what the change does.
2. Keep it Short and Sweet: The first line should be 72 characters or less. The body, if needed, should be wrapped at a maximum 80 characters (the commit linter will fail if any line is longer than 100 characters).
3. Use the Imperative Mood: Start the message with a verb (e.g., "add," "fix," "remove").
4. Use Proper Punctuation: Lowercase the first letter of the type and the description, and do not end the description with a period.

Example Commit Message with Body and Footer

feat(auth): add OAuth2 authentication

This adds OAuth2 authentication to the user service, allowing users
to log in with their Google account.

BREAKING CHANGE: The login endpoint now requires a different payload.

Closes #123

By following these guidelines, you ensure that your commit messages are clear, consistent, and useful for anyone who might read them in the future.

Following the Conventional Commits specification helps in creating a well-maintained and understandable project history, which can significantly improve collaboration and productivity in software development.

[petermetz]

@rajat-dlt Please see my question about the golang upgrade as well.

[rajat-dlt]

@petermetz ,

Thank you very much for your suggestions. I have incorporated the changes accordingly.

[petermetz]

Added this to the description as well. According to the documentation available at Hyperledger Fabric, we needed to upgrade to a specific Go version. The script was failing with the error unknown directive: toolchain, which is due to the toolchain directive being introduced in Go 1.21. Ensure you are using Go 1.21 or later.

Oops, my bad! Thank you for confirming! LGTM

[petermetz]

@rajat-dlt Thank you again for the contribution!

[rajat-dlt]

This closes issue #3335 .