docs: improve release-facing documentation for v0.2#9
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #6
This docs-only change improves the release-facing documentation for the v0.2 milestone so external readers can understand what LogLens ships today, what it produces at runtime, and how future release notes should be maintained. Before this branch, the repository explained the project and its detections, but it did not yet give release-oriented readers a durable changelog workflow or a clearly separated place to capture user-visible history over time.
The effect for users and maintainers is that release information is now easier to find and easier to keep consistent. The README now points readers to the release-facing documentation set, includes sample Markdown and JSON output excerpts, and tightens the limitations language so parser and detector boundaries are clearer to people evaluating the tool from the outside. A new CHANGELOG establishes a stable structure for tracking user-visible changes across versions, and the new release-process note explains where README content, changelog entries, and GitHub release notes belong so future releases stay concise and credible.
The root issue behind #6 was documentation drift risk: release details were either implicit or spread across the repository, which makes future versions harder to communicate cleanly. This change addresses that by centralizing changelog discipline, surfacing release-facing samples, and clarifying current MVP constraints without adding duplicate or unsafe content. No source code or detection behavior changed in this PR.
For validation, I confirmed that the branch diff is limited to README and documentation files only. I also attempted to run the local CMake build and test flow, but
cmakeis not available in the current shell environment, so the merge gate for this docs-only PR is the repository's GitHub Actions checks (CI and CodeQL).