Create v2 version branch for production-ready cache implementations with breaking changes

[Copilot]

This PR creates a new v2 version branch to properly handle the major breaking changes that transform grc from an interface-only library to one that provides both a clean interface and production-ready default implementations.

Why v2.0?

The changes introduce breaking changes that warrant a major version bump:

• Module path change: github.com/evangwt/grc → github.com/evangwt/grc/v2
• API restructuring: Moving implementations from examples to production defaults
• Import changes: All existing users will need to update their import statements

Key Changes in v2.0

🚀 Production-Ready Built-in Implementations

• Moved cache implementations from examples/implementations/ to root level as production defaults
• Clean naming: grc.NewMemoryCache() and grc.NewRedisClient() instead of example-style names
• Production-ready: Thread-safe, tested implementations ready for production use
• Simple API: No need to import from examples - everything available directly from grc package

🎯 Simplified Usage

Before (v1 - complex):

import "github.com/evangwt/grc/examples/implementations"
cache := grc.NewGormCache("cache", implementations.NewMemoryCache(), config)

After (v2 - simple):

import "github.com/evangwt/grc/v2"
cache := grc.NewGormCache("cache", grc.NewMemoryCache(), config)

📚 Focused Documentation

• Simplified README: Clear, concise documentation focused on core functionality
• Easy quick start: Get started with built-in implementations immediately
• Interface flexibility preserved: Users can still implement custom cache clients

Migration Guide

To upgrade from v1 to v2:

1. Update your import statement:

   // Old (v1)
   import "github.com/evangwt/grc"
   
   // New (v2)
   import "github.com/evangwt/grc/v2"

2. Use built-in implementations directly:

   // v2 - Simple and clean
   cache := grc.NewGormCache("cache", grc.NewMemoryCache(), config)

Performance & Features

All existing performance optimizations are preserved:

• 28% faster cache key generation with configurable hashing strategies
• Timeout support for cache operations with graceful error handling
• Thread-safe operations with automatic cleanup
• Type-safe context keys for better API design

Technical Details

• Module versioning: Proper Go module v2 versioning following best practices
• Backward compatibility: v1 remains available for existing users
• Test coverage: All tests pass with v2 module structure
• Documentation: Updated README and examples for v2 imports

This change makes grc both powerful (through its interface) and approachable (through its defaults) while properly versioning breaking changes as v2.0.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[evangwt]

@copilot The implement of redis and memory cache is nice. But user can use their implements are better.

[evangwt]

@copilot An abstract cache interface with a default implement is better.
Users can implement a custom cache like memory, redis, memcache etc.

[Copilot]

@copilot The implement of redis and memory cache is nice. But user can use their implements are better.

You're absolutely right! I've refactored the library to prioritize user implementations over built-in ones.

Changes made (commit 5e7b76e):

• Moved NewMemoryCache() and SimpleRedisClient to examples/implementations/ directory
• Updated README to emphasize interface-first approach with popular libraries (go-redis, go-cache, BigCache)
• Added integration examples showing how to wrap established cache libraries
• Made it clear that the examples are reference implementations for learning, not production use

Why this approach is better:

• Users can leverage battle-tested libraries like go-redis, go-cache
• Reduces vendor lock-in - users aren't tied to our specific implementations
• Encourages best practices - use production-ready libraries instead of built-in ones
• Library focuses on its core value: the clean CacheClient interface abstraction

The library now clearly follows "your cache implementation is YOUR choice - grc provides the elegant interface."

[evangwt]

@copilot these implementations should use a production-ready naming rule for users to use. The examples folder is not that production-ready. These implementations are default options for users and they can use others which implement the interface definition. Provide simple apis for users. Easy to use is best.
Keep readme simple and clear. Do what README really should do.

[Copilot]

@copilot these implementations should use a production-ready naming rule for users to use. The examples folder is not that production-ready. These implementations are default options for users and the...

I've restructured grc to provide production-ready default implementations with simple APIs as requested.

Changes made (commit d204fac):

• Moved implementations to root level: grc.NewMemoryCache() and grc.NewRedisClient() are now production-ready defaults
• Production-ready naming: Clean, professional names instead of "examples"
• Simple API: Easy-to-use built-in implementations ready for production
• Simplified README: Focused on core functionality with clear, concise documentation
• Interface-first design preserved: Users can still implement custom cache clients
• Comprehensive tests: Added full test coverage for built-in implementations

The library now provides the best of both worlds: simple defaults for easy adoption while maintaining the flexible interface design you requested.

[evangwt]

This PR should create a new v2 version branch to merge it. @copilot

[Copilot]

This PR should create a new v2 version branch to merge it. @copilot

I've created the v2 branch as requested (commit c3e2ce8). The changes include:

• Updated module path to github.com/evangwt/grc/v2
• Updated all import statements in README and examples
• Verified all tests pass with the v2 module structure

The v2 branch properly handles the breaking changes and follows Go module versioning best practices for major version updates.