Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,9 +32,11 @@ Enhancement suggestions are tracked as GitHub issues. When creating an enhanceme
1. Fork the repo and create your branch from `main`
2. If you've added code that should be tested, add tests
3. Ensure your code follows the existing style
4. Write a clear commit message describing your changes
4. **Use a conventional commit format for your PR title** (e.g., `feat(node): add version caching`)
5. Submit your pull request!

**Note:** We use squash merges, so your PR title becomes the commit message on main. Make sure it follows the [commit convention](docs/COMMIT_CONVENTION.md).

## Development Setup

### Prerequisites
Expand Down Expand Up @@ -196,7 +198,7 @@ test(migrate): add tests for package preservation

For detailed guidelines and examples, see [Commit Convention Guide](docs/COMMIT_CONVENTION.md).

**Note:** Pull requests are automatically checked for commit message compliance. Non-conforming commits will fail CI checks.
**Note:** PR titles are automatically validated for conventional commit compliance. Non-conforming titles will fail CI checks. Since we use squash merges, your PR title becomes the final commit message.

## Adding a New Runtime Provider

Expand Down
14 changes: 10 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -134,13 +134,19 @@ dtvem freeze
dtvem install # Prompts for confirmation
dtvem install --yes # Skip confirmation

# Check currently active versions
# Check currently active versions (all runtimes)
dtvem current

# List installed versions
# Check active version for specific runtime
dtvem current python

# List all installed versions (all runtimes)
dtvem list

# List installed versions for specific runtime
dtvem list python

# List all available versions
# List all available versions for download
dtvem list-all python

# List with filtering
Expand Down Expand Up @@ -297,7 +303,7 @@ This scans all installed versions and creates shims for every executable found,
| `init` | Initialize dtvem (setup directories and PATH) | ✅ Complete |
| `install [runtime] [version]` | Install a specific runtime version, or all from `.dtvem/runtimes.json` | ✅ Complete |
| `uninstall <runtime> <version>` | Remove an installed version | ✅ Complete |
| `list <runtime>` | List installed versions | ✅ Complete |
| `list [runtime]` | List installed versions (all runtimes or specific) | ✅ Complete |
| `list-all <runtime>` | List all available versions (with filtering) | ✅ Complete |

### Version Management
Expand Down
30 changes: 26 additions & 4 deletions docs/COMMIT_CONVENTION.md
Original file line number Diff line number Diff line change
Expand Up @@ -70,18 +70,20 @@ The scope should be the name of the affected module or component:
The subject contains a succinct description of the change:

- Use the imperative, present tense: "add" not "added" nor "adds"
- Don't capitalize the first letter
- Start with lowercase (but uppercase abbreviations like PR, API, CLI, URL are allowed)
- No period (.) at the end
- Maximum 72 characters

**Good examples:**
- `fix(python): handle missing pip.exe on Windows`
- `feat(cli): add --yes flag to install command`
- `docs: add troubleshooting section to README`
- `chore(ci): remove PR coverage comments`
- `feat: add API endpoint for version lookup`

**Bad examples:**
- `Fixed bug` (missing scope, not descriptive)
- `feat(node): Added support for nvm.` (wrong tense, capitalized, period)
- `Fixed bug` (missing type, not descriptive)
- `feat(node): Added support for nvm.` (wrong tense, period at end)
- `Update code` (missing type, not descriptive)

### Body (Optional)
Expand Down Expand Up @@ -156,9 +158,29 @@ Reverting due to Windows compatibility issues that need more investigation.
Relates to #234
```

## Pull Requests and Squash Merges

This project uses **squash merges** for all pull requests. This means:

- All commits in your PR are combined into a single commit on merge
- **The PR title becomes the commit message** on the main branch
- Your PR title must follow the conventional commit format

When creating a PR, ensure your title follows the format:
```
<type>(<scope>): <subject>
```

For example:
- `feat(node): add support for Node.js 22.x`
- `fix(shim): handle API errors on Windows`
- `chore(ci): update PR linting workflow`

The PR title is validated automatically - if it doesn't follow the convention, the CI check will fail.

## Validation

All commits in pull requests are automatically validated using [commitlint](https://commitlint.js.org/). If your commits don't follow this convention, the CI check will fail.
Both PR titles and individual commits are automatically validated using [commitlint](https://commitlint.js.org/). If they don't follow this convention, the CI check will fail.

### Tips for Success

Expand Down