[Release]v6.0.0

[JKamsker]

This pull request introduces a comprehensive overhaul to the project's build, test, versioning, and release automation, as well as updates to project documentation and target frameworks. The changes modernize the CI/CD pipeline with GitHub Actions, standardize versioning using GitVersion, update project files to target .NET 8, and provide new documentation for contributors. Additionally, minor code improvements and new utility projects are included.

CI/CD and Versioning Automation:

• Added multiple GitHub Actions workflows for CI, prerelease publishing, release publishing, and version tagging, automating build, test, packaging, and deployment processes (.github/workflows/ci.yml, .github/workflows/publish-prerelease.yml, .github/workflows/publish-release.yml, .github/workflows/tag-version.yml). [1] [2] [3] [4]
• Introduced GitVersion for semantic versioning, including configuration files and MSBuild integration (GitVersion.yml, .config/dotnet-tools.json, Directory.Build.props). [1] [2] [3]

Project Structure and Documentation:

• Added AGENTS.md with detailed repository guidelines covering project structure, build/test commands, coding standards, testing, commit/PR practices, and versioning.
• Added a new sample project LiteDB.RollbackRepro for reproducible test scenarios.

Target Framework and Build Updates:

• Updated all major project files to target .NET 8 (net8.0) and set language version to latest where appropriate, removing legacy framework targets (LiteDB.Benchmarks/LiteDB.Benchmarks.csproj, LiteDB.Shell/LiteDB.Shell.csproj, LiteDB.Stress/LiteDB.Stress.csproj). [1] [2] [3]

Code Quality and Testing Improvements:

• Marked test and report threads as background threads in stress test execution to improve shutdown behavior (LiteDB.Stress/Test/TestExecution.cs). [1] [2]
• Enabled disk write failure simulation in both debug and testing builds (ConsoleApp1/Program.cs).
• Added missing test utility namespace import to LiteDB.Tests/Database/AutoId_Tests.cs.

[Copilot]

Pull Request Overview

This pull request implements a comprehensive modernization of LiteDB's development and release infrastructure while introducing multi-field sorting capabilities to the query engine. The changes include migration from AppVeyor to GitHub Actions, introduction of GitVersion for semantic versioning, target framework updates to .NET 8, and significant enhancements to the ORDER BY functionality supporting multiple sort keys.

Key changes:

• Complete CI/CD modernization with GitHub Actions workflows for builds, testing, and automated releases
• Implementation of multi-field ORDER BY support with new ThenBy/ThenByDescending methods
• Project structure improvements including new test utilities and updated target frameworks

Reviewed Changes

Copilot reviewed 101 out of 102 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
.github/workflows/	New CI/CD workflows for automated testing, prerelease publishing, release publishing, and version tagging
GitVersion.yml	GitVersion configuration for semantic versioning with branch-specific policies
LiteDB/Engine/Query/	Enhanced query engine with multi-field sorting support via new OrderBy, SortKey, and SortContainer classes
LiteDB/Client/Database/	Extended public API with ThenBy/ThenByDescending methods for multi-field sorting
LiteDB.Tests/	Comprehensive test coverage for new sorting functionality and updated test infrastructure
LiteDB/LiteDB.csproj	Updated target frameworks to netstandard2.0 and net8.0, removed legacy framework support

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The null check should be performed before assigning _disk to follow fail-fast principles and avoid partial object initialization in case of argument validation failure.

[Copilot]

There's a potential race condition or logic error: this.Count depends on the base constructor completing with the transformed values, but if the values enumerable is consumed multiple times with different results, the length validation could be incorrect. Consider storing the values array first and validating lengths before calling the base constructor.

Suggested change

	: base(values?.Select(x => x ?? BsonValue.Null) ?? throw new ArgumentNullException(nameof(values)))
	{
	if (orders == null) throw new ArgumentNullException(nameof(orders));
	_orders = orders as int[] ?? orders.ToArray();
	if (_orders.Length != this.Count)
	{
	throw new ArgumentException("Orders length must match values length", nameof(orders));
	}
	}
	: base((values == null ? throw new ArgumentNullException(nameof(values)) : values.Select(x => x ?? BsonValue.Null)).ToArray())
	{
	if (orders == null) throw new ArgumentNullException(nameof(orders));
	_orders = orders as int[] ?? orders.ToArray();
	// Since we materialized values above, we can safely use this.Count
	if (_orders.Length != this.Count)
	{
	throw new ArgumentException("Orders length must match values length", nameof(orders));
	}

[Copilot]

When value is already a SortKey, returning it directly ignores the provided orders parameter, which could lead to incorrect sorting behavior if the existing SortKey has different ordering requirements than expected.

[Copilot]

For single-segment sorting, creating a new array new[] { segment.Order } for each method call is inefficient. Consider caching common single-element arrays or passing the order directly to avoid unnecessary allocations.

[Copilot]

The error message suggests using ThenBy for additional sort keys, but the restriction prevents multiple OrderBy calls entirely. This breaks the fluent API pattern where multiple OrderBy calls could reasonably reset the sort criteria. Consider allowing multiple OrderBy calls by clearing the existing OrderBy list instead of throwing an exception.

[Copilot]

Setting MaxCpuCount to 1 and disabling parallelization may significantly slow down CI builds. Consider using a higher CPU count (e.g., 2-4) while still maintaining stability, as completely disabling parallel execution eliminates the benefits of modern CI infrastructure.

Suggested change

	<MaxCpuCount>1</MaxCpuCount> <!-- Single-threaded to avoid resource contention -->
	<DisableParallelization>true</DisableParallelization>
	<MaxCpuCount>4</MaxCpuCount> <!-- Use 4 CPUs for parallel test execution -->