docs: add initial CHANGELOG and CONTRIBUTING guidelines

docs: add initial CHANGELOG and CONTRIBUTING guidelines

Author: DeRuina

CHANGELOG.md

@@ -0,0 +1,23 @@
+# Changelog
+
+## [1.1.0] - 2025-05-27
+
+### Added
+- Support for time-based log rotation via `RotationInterval` configuration
+- Rotation reason (`-time`, `-size`) included in backup filenames
+- Platform-specific file ownership preservation (`chown_linux.go`)
+- Enhanced filename parsing to recognize timestamp and rotation reason
+- Extensive unit tests for time-based rotation, compression, and ownership
+- Default filename uses `-timberjack.log` if none is provided
+
+### Changed
+- Refactored rotation logic to support time-based, size-based, and manual triggers uniformly
+- Replaced deprecated `ioutil.ReadDir` with modern `os.ReadDir`
+- Improved compression logic to handle chown and cleanup safely
+
+### Fixed
+- Preserved original file mode and ownership during rotation and compression
+- Resolved edge cases in backup name parsing with improved robustness
+
+### Removed
+- Legacy logic relying solely on size-based rotation

CONTRIBUTING.md

@@ -0,0 +1,62 @@
+# Contributing to Timberjack
+
+Thank you for considering contributing to **Timberjack**! Please take a moment to read through these guidelines.
+
+## Guidelines
+
+- All contributions must follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0) format.
+- Ensure all tests pass before pushing or opening a pull request.
+- Document new functionality clearly in code comments and README if applicable.
+- Avoid unnecessary commits or unrelated changes.
+
+## Commit Message Format
+
+We follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) standard:
+
+```
+<type>[optional scope]: <description>
+```
+### Examples
+
+- `feat: add Rotate feature`
+- `fix: correct rotation timestamp logic`
+- `docs: update README with usage example`
+- `test: cover edge case for rotation overlap`
+
+### Allowed Types
+
+| Type      | Use For                                                                 |
+|-----------|-------------------------------------------------------------------------|
+| `feat`    | A new feature                                               |
+| `fix`     | A bug fix                                             |
+| `chore`   | Build process, CI, tooling                        |
+| `docs`    | Changes to documentation (README, comments)                             |
+| `test`    | Adding or modifying tests                                               |
+| `refactor`| Code refactoring without behavior change               |
+| `style`   | Code style changes (whitespace, etc)                                      |
+| `perf`    | Performance improvements                                                |
+| `ci`      | Changes to GitHub Actions, CI/CD workflows                              |
+
+
+## Scopes (Optional)
+
+Use a **scope** in parentheses after the type to clarify what part of the code is affected. Examples:
+
+- `fix(logger): correct timestamp handling`
+- `feat(rotation): add weekday scheduling`
+- `docs(readme): document Rotate usage`
+
+### Breaking Changes
+
+If your commit introduces a **breaking change** — something that would require users to modify their code — add a `!` immediately after the type:
+
+- `feat!: remove support for deprecated config field`
+
+This will mark the commit as a major version bump when release automation is used.
+
+### Other Guidelines
+
+- Run all tests before pushing: `go test ./...`
+- Keep PRs focused and self-contained
+- Use clear, descriptive commit messages
+- If you add a new feature, consider adding an example in the README.