Code Release Tracker is an Electron desktop application for managing software releases and the repositories that ship inside them. It is built with React, TypeScript, Vite, and Electron.
The application lets teams:
- create and track releases
- attach repositories with versions and optional tags
- monitor monthly and quarterly release coverage
- import and export tracker data locally
Current app version: 0.2.5
For releases, keep the package.json version and Git tag aligned. Example: 0.2.3 in package.json should be released as v0.2.3.
Install dependencies:
npm installRun the app in development:
npm run devRun linting:
npm run lintRun type-checking:
npm run buildNote: in this environment, npm run build may still hit a Vite spawn EPERM issue when loading vite.config.ts. tsc -b and eslint . are the more reliable local verification commands here.
Themis tests are available through npm run test.
If you need to regenerate Themis coverage, run npm run test:generate.
Build a Windows installer locally:
npm run dist:winThat command runs the app build first, then packages the Electron app with electron-builder.
After it finishes, look in the release folder for:
Code Release Tracker Setup 0.2.5.exe: the Windows installerwin-unpacked: the unpacked app directory
To install locally:
- Open the
releasefolder. - Double-click
Code Release Tracker Setup 0.2.5.exe. - Follow the setup wizard to install the app.
If you want to test without installing, open the win-unpacked folder and run Code Release Tracker.exe directly.
The packaged app checks GitHub Releases on startup for updates and prompts you to restart after a downloaded update is ready.
You can also use File > Check for updates inside the app to run the same check manually.
src/App.tsx: main application UI and state managementsrc/App.css: application stylingsrc/index.css: global styling and background treatmentelectron.cjs: Electron main processpreload.js: Electron preload bridge
This project is open source and contributions are welcome.
If you want to contribute:
- Fork the repository and create a focused branch for your change.
- Keep changes scoped. Avoid mixing UI work, refactors, and behavioral changes in one patch unless they are tightly related.
- Run verification before opening a pull request:
npm run build
npm run lint
npm run test- Include a clear summary of what changed, why it changed, and how it was tested.
- For UI changes, include screenshots or a short screen recording.
- For destructive actions or workflow changes, document the user impact explicitly.
- Preserve existing user data behavior unless a migration path is included.
- Prefer small, reviewable changes over large rewrites.
- Keep naming consistent with the release/repository model already used in the app.
- Do not commit generated files or unrelated formatting churn.
- If you add a new feature, update this README when the workflow changes.
- Bug reports should include reproduction steps, expected behavior, and actual behavior.
- Feature requests should explain the release-tracking use case they improve.
- Pull requests should stay implementation-focused and avoid bundling unrelated cleanup.