vrr/vpnhide
2
0
Fork 0
mirror of https://github.com/okhsunrog/vpnhide.git synced 2026-05-22 19:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
vpnhide/CONTRIBUTING.md
okhsunrog ad2590a453 refactor(scripts): unreleased section + rename scripts 
Rework the changelog and release flow to remove the aspirational
top-level version that made it unclear whether new entries were
landing in an already-released section.

Schema change: `changelog.json` now has an explicit `unreleased`
object instead of hoisting the upcoming version to the top level. The
old `{version, sections, history}` layout becomes
`{unreleased, history}`, with the previously-released version moved
into `history[0]`.

New entries always go into `unreleased` via `changelog.py`. Releasing
is a single atomic operation (`release.py X.Y.Z`) that promotes
`unreleased` into `history[0]` with the target version number,
propagates the version to every source file, and regenerates the
markdown artifacts.

Script renames:
- `_changelog.py` → `changelog_lib.py` (no more underscore-prefixed
  module that's imported by two siblings)
- `changelog-add.py` → `changelog.py`
- `update-version.py` → `release.py` (does more than just version
  propagation — the name now reflects the full release action)

CHANGELOG.md rendering follows Keep a Changelog: a `## [Unreleased]`
block appears on top only when there are unreleased entries; the
update-json/changelog.md shown in Magisk/KSU popups still skips
Unreleased (only released versions make sense there).

Docs (docs/changelog.md, docs/releasing.md, CONTRIBUTING.md, CLAUDE.md)
updated with the new commands and the clarified model.

CLAUDE.md additionally gains a "read these before doing any work"
section that lists the contributor docs — so future sessions load the
workflow rules into context instead of skipping them as optional.
2026-04-17 14:34:47 +03:00

2.1 KiB
Raw Permalink Blame History

Contributing to vpnhide

Thanks for your interest. This file covers the contribution process; for build and setup instructions see docs/development.md.

Before you start

  • For non-trivial changes, open an issue first to discuss the approach.
  • Make sure your change builds locally and passes the CI lints listed in docs/development.md.

Commits

Use conventional-style prefixes, matching the existing history:

  • fix: — bug fix
  • feat: — new feature
  • refactor: — code change without behaviour change
  • docs: — documentation only
  • chore: — tooling, release, CI, build
  • ci: — CI-only changes

Scope the prefix where useful: fix(zygisk): …, feat(lsposed): …, fix(kmod): ….

Keep messages focused on why, not what — the diff already shows what changed.

Changelog entry (required for user-visible changes)

Before opening a PR, add a changelog entry:

./scripts/changelog.py <type> "<EN text>" "<RU text>"
# types: added | changed | fixed | removed | deprecated | security

This appends to the unreleased section of lsposed/app/src/main/assets/changelog.json and regenerates CHANGELOG.md and update-json/changelog.md. Commit all three files with your change.

Skip the entry for internal refactors with no behaviour change, docs-only, CI-only, and test-only changes.

See docs/changelog.md for the full changelog workflow.

Pull requests

  • Target the main branch.
  • Keep PRs focused — one logical change per PR.
  • Include a "why" in the PR description, and a brief "Testing" section if you verified anything manually that CI doesn't cover (hardware testing, specific device models, edge cases).
  • CI must pass before merge.

Code style

All style is enforced by CI — run the checks locally before pushing:

  • Rust: cargo fmt + cargo clippy -- -D warnings
  • C: clang-format against kmod/vpnhide_kmod.c
  • Kotlin: ktlint
  • Android: ./gradlew :app:lint

License

By contributing, you agree that your contributions will be licensed under the MIT License that covers the project.