This guide helps contributors and readers navigate deployment history, release notes, and our branching/tagging strategy in the ALL-IN-ONE project.
1. Checking Deployments
- Visit: [GitHub → Deployments](https://github.com/cevherdogan/all-in-one/deployments)
- Each deployment entry shows:
- **Environment** (e.g., `github-pages`)
- **Commit hash**
- **Deployed by**
- **Timestamp**
- Use this to confirm when the latest content went live.
2. Reading Release Notes
- Release notes summarize what changed in a given tagged version.
- Future releases will include:
- **New articles/guides**
- **Template updates**
- **Automation improvements**
- Access: GitHub → **Releases** tab.
3. CHANGELOG.md
- The `CHANGELOG.md` file lists changes in chronological order.
- Format:
```
[vX.Y.Z] - YYYY-MM-DD
### Added
- New content or feature
### Changed
- Updates to existing pages
### Fixed
- Bug fixes or corrections
```
- Contributors should update it for every meaningful change.
4. Tagging Strategy
- Semantic versioning: `vMAJOR.MINOR.PATCH`
- **MAJOR**: Breaking changes
- **MINOR**: New content/features
- **PATCH**: Fixes or minor updates
- Example:
- `v1.0.0` — initial public release
- `v1.1.0` — added 3 new guides
- `v1.1.1` — fixed typos and links
5. Branching Strategy
- `main` is **locked** — direct pushes are disabled.
- All changes come through **Pull Requests** from forks.
- Suggested branch naming:
- `feature/
` — new content or functionality - `fix/
` — bug or typo fixes - `docs/
` — documentation-only changes - PRs must:
- Pass automated checks
- Be reviewed and approved
6. Why This Matters
- **Transparency**: Clear history of what was deployed and when.
- **Quality Control**: Peer review ensures accuracy and consistency.
- **Traceability**: Tags and changelog entries help track features across versions.
Community Learning
Following this guide ensures everyone — maintainers, contributors, and readers — can easily:
- See what’s new
- Understand the workflow
- Join the project without guesswork