-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
V2.8.42 #911
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
V2.8.42 #911
Changes from all commits
0a0aaeb
57b5e6e
933038c
54b803c
e2a8bd8
0bcf8bc
81efefb
9e558a0
a9bfc42
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,143 @@ | ||
| # MySQLTuner Commit and Release Process Guide | ||
|
|
||
| This document describes the mandatory workflow for committing changes and releasing new versions of MySQLTuner. Following this process ensures quality, formatting consistency, version integrity, and metadata compliance. | ||
|
|
||
| --- | ||
|
|
||
| ## 🛠️ 1. Commit Process | ||
|
|
||
| Every contribution to MySQLTuner must pass through a strict formatting, code generation, testing, and commit linting pipeline before being pushed. | ||
|
|
||
| ### Step 1.1: Development Branching | ||
| All changes (features, bug fixes, chore, etc.) MUST be done in a dedicated Git branch separated from `master`. Committing directly to the `master` branch is strictly prohibited. | ||
|
|
||
| ### Step 1.2: Code Formatting | ||
| Ensure that `mysqltuner.pl` matches the project formatting standard: | ||
| ```bash | ||
| make tidy | ||
| ``` | ||
| *Behind the scenes*: This formats the code with `perltidy` using the project's config [.perltidy](file:///.perltidy) and cleans up file line endings with `dos2unix`. | ||
|
|
||
| To check if the formatting is correct without modifying the file: | ||
| ```bash | ||
| make check-tidy | ||
| ``` | ||
|
|
||
| ### Step 1.3: Generate Required Assets | ||
| If your changes affect CLI options, documentation, vulnerability lists, or support metadata, run the appropriate generators before committing: | ||
| * **Documentation (USAGE.md)**: Rebuild the markdown usage guide from the Perl POD: | ||
| ```bash | ||
| make generate_usage | ||
| ``` | ||
| * **Features List (FEATURES.md)**: Re-extract subroutines list: | ||
| ```bash | ||
| make generate_features | ||
| ``` | ||
| * **CVE Vulnerabilities (vulnerabilities.csv)**: Fetch the latest security vulnerability definitions: | ||
| ```bash | ||
| make generate_cve | ||
| ``` | ||
| * **End-of-Life Support Files (mysql_support.md, mariadb_support.md)**: Re-extract MySQL and MariaDB EOL dates: | ||
| ```bash | ||
| make generate_eof_files | ||
| ``` | ||
| * **Current Version File (CURRENT_VERSION.txt)**: Keep the version file in sync: | ||
| ```bash | ||
| make generate_version_file | ||
| ``` | ||
|
|
||
| ### Step 1.4: Run Automated Tests | ||
| Validate your changes locally using both unit tests and multi-database lab testing: | ||
| 1. **Unit & Regression Tests**: | ||
| ```bash | ||
| make unit-tests | ||
| # or | ||
| prove -r tests/ | ||
| ``` | ||
| 2. **Laboratory Tests (Docker)**: | ||
| Ensure code executes correctly across multiple database versions (MySQL, MariaDB, Percona Server): | ||
| ```bash | ||
| make test | ||
| # or run all environments | ||
| make test-all | ||
| ``` | ||
|
|
||
| ### Step 1.5: Commit via Conventional Commits | ||
| All commits must follow the standard [Conventional Commits](https://www.conventionalcommits.org/) specification: | ||
| * **Allowed Types**: `feat`, `fix`, `chore`, `docs`, `perf`, `refactor`, `style`, `test`, `ci` | ||
| * **Format**: `<type>(<scope>): <short summary>` followed by optional body/footer. | ||
| * **Interactive Tool**: To guarantee compliance, commit using: | ||
| ```bash | ||
| npm run commit | ||
| # or | ||
| git cz | ||
| ``` | ||
|
|
||
| ### Step 1.6: Commit Hooks Enforcement | ||
| Husky enforces validation at commit time: | ||
| * **`pre-commit` Hook**: Automatically triggers `npm test` (`prove tests/*.t`). If unit tests fail, the commit is blocked. | ||
| * **`commit-msg` Hook**: Validates the commit message structure against Conventional Commit rules using `commitlint`. | ||
|
|
||
| --- | ||
|
|
||
| ## 🚀 2. Release Process | ||
|
|
||
| The release lifecycle is governed by automated pre-flight checks and note generators to guarantee stability and release integrity. | ||
|
|
||
| ### Step 2.1: Open a Release Branch | ||
| Cut a release branch named after the target version (e.g., `v2.8.42`): | ||
| ```bash | ||
| git checkout -b vX.XX.XX | ||
| ``` | ||
|
|
||
| ### Step 2.2: Synchronize Version Numbers | ||
| Ensure the target version is synchronized across all of the following locations: | ||
| 1. [CURRENT_VERSION.txt](file:///CURRENT_VERSION.txt) | ||
| 2. [mysqltuner.pl](file:///mysqltuner.pl) header (`# mysqltuner.pl - Version X.XX.XX`) | ||
| 3. [mysqltuner.pl](file:///mysqltuner.pl) internal variable (`our $tunerversion = "X.XX.XX"`) | ||
| 4. [mysqltuner.pl](file:///mysqltuner.pl) POD Name (`MySQLTuner X.XX.XX - MySQL High Performance`) | ||
| 5. [mysqltuner.pl](file:///mysqltuner.pl) POD Version (`Version X.XX.XX`) | ||
| 6. [Changelog](file:///Changelog) latest version header line (`X.XX.XX YYYY-MM-DD`) | ||
|
|
||
| To update version strings automatically across the codebase, use one of: | ||
| ```bash | ||
| make increment_sub_version # Bumps micro/sub version (e.g. 2.8.41 -> 2.8.42) | ||
| make increment_minor_version # Bumps minor version (e.g. 2.8.41 -> 2.9.0) | ||
| make increment_major_version # Bumps major version (e.g. 2.8.41 -> 3.0.0) | ||
| ``` | ||
|
|
||
| ### Step 2.3: Update the Changelog & Generate Release Notes | ||
| 1. Add detailed bullet points in [Changelog](file:///Changelog) under the new version header, categorized by Conventional Commit types (`chore`, `feat`, `fix`, `test`, `ci`, etc.). | ||
| 2. Run the `/release-notes-gen` workflow (or script directly) to analyze the changelog, delta indicator metrics, and generate/update the corresponding release notes file: | ||
| ```bash | ||
| python3 build/release_gen.py | ||
| ``` | ||
| *Behind the scenes*: This compiles the release summary, diagnostic growth statistics, commit differences, and CLI modifications into [releases/](file:///releases/) (e.g., `releases/v2.8.42.md`). | ||
|
|
||
| ### Step 2.4: Execute Release Preflight Checks | ||
| Run the preflight checks to guarantee zero configuration mismatch and 100% compliance: | ||
| ```bash | ||
| /release-preflight | ||
| ``` | ||
| *Behind the scenes*: This workflow: | ||
| 1. Verifies version consistency across files (via [tests/version_consistency.t](file:///tests/version_consistency.t)). | ||
| 2. Verifies that release notes exist in `releases/v[VERSION].md`. | ||
| 3. Checks that all commit messages follow conventional commits since the last tag. | ||
| 4. Checks project documentation formatting and metadata compliance. | ||
| 5. Validates `mysqltuner.pl` code formatting (`make check-tidy`). | ||
| 6. Runs the smoke test suite (`make test`). | ||
|
|
||
| ### Step 2.5: Tag and Push (Unified Release Manager) | ||
| The final tag and push sequences are automated by the `/release-manager` workflow: | ||
| 1. Verify you are on the release branch. | ||
| 2. Commit all synchronized documentation and release notes. | ||
| 3. Perform release tagging: | ||
| ```bash | ||
| git tag -a vX.XX.XX -m "Release X.XX.XX" -m "Release notes contents..." | ||
| ``` | ||
| 4. Push the branch and release tag: | ||
| ```bash | ||
| git push origin vX.XX.XX | ||
| git push origin refs/tags/vX.XX.XX | ||
| ``` | ||
| 5. Merge back into `master` and ensure tags are force pushed to origin to sync the workspace. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1 @@ | ||
| 2.8.41 | ||
| 2.8.42 |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,15 @@ | ||
| # MySQL and MariaDB Authentication Plugins Reference | ||
|
|
||
| This document provides a comprehensive overview of authentication plugins across MySQL and MariaDB, including security levels, deprecation status, and platform support. | ||
|
|
||
| ## Summary Table | ||
|
|
||
| | Plugin Name | Description | Algorithm | Security Level | Deprecated / Obsolete | Present in MySQL | Present in MariaDB | | ||
| | :--- | :--- | :--- | :--- | :--- | :--- | :--- | | ||
| | `mysql_native_password` | Historical default authentication method. | SHA-1 | Low | Yes (Removed from MySQL 8.4+ / Deprecated in MariaDB) | ✅ (Obsolete) | ✅ (Historical default) | | ||
| | `mysql_old_password` | Ancient pre-4.1 authentication method. | SHA-1 (Old) | Very Low | Yes (Removed) | ❌ | ✅ (Obsolete) | | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🧩 Analysis chain🌐 Web query:
💡 Result: The mysql_old_password plugin uses a legacy, insecure pre-4.1 password hashing algorithm, not SHA-1 [1][2][3]. This algorithm produces a 16-byte hash value [1][4][5]. In contrast, the newer 4.1+ authentication method (mysql_native_password) utilizes a double-SHA-1 hashing process and produces a 41-byte hash value [1][4][6]. The mysql_old_password plugin and its associated pre-4.1 hashing method are considered obsolete and insecure [2][3][7]. Support for this plugin and the pre-4.1 hash format was removed in MySQL 5.7.5 [1][5]. While it remains available in some environments for backward compatibility, it is strongly recommended to migrate to more secure authentication plugins such as caching_sha2_password or ed25519 [2][8][9]. Citations:
Fix documentation: 🤖 Prompt for AI Agents |
||
| | `sha256_password` | Authenticates using SHA-256 with salting. | SHA-256 | High | Yes (Due to CPU scalability issues without TLS) | ❌ (Removed in 8.4) | ✅ | | ||
| | `caching_sha2_password` | Optimized version of SHA-256 with memory caching. | SHA-256 | High | No | ✅ (Default since 8.0) | ✅ (Since v11.4 for compatibility) | | ||
| | `unix_socket` | Authentication via OS-level user identity (UID). | OS Identity | Very High | No | ✅ (as `auth_socket`) | ✅ | | ||
| | `ed25519` | Elliptic Curve digital signature algorithm (EdDSA). | Ed25519 | Very High | No | ❌ (Except via third-party Enterprise modules) | ✅ | | ||
| | `parsec` | Password Authentication using Response Signed with Elliptic Curve (new MariaDB standard). | PBKDF2 + SHA-512 + Ed25519 | Maximal | No | ❌ | ✅ | | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Date discrepancy in release metadata.
The Changelog entry is dated 2026-05-25, but the PR description states "Release 2.8.42 dated 2026-05-17". I've seen enough version-bump commits to know this usually means someone copy-pasted the wrong date somewhere.
Which date is the official release date? If it's 2026-05-25, the PR description should be updated. If it's 2026-05-17, this Changelog date and the corresponding
releases/v2.8.42.mddate need correction.🤖 Prompt for AI Agents