serde-structprop 0.1.3

Serde serializer and deserializer for the structprop config file format
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128

# Contributing to serde-structprop

Thank you for your interest in contributing. This document covers everything
you need to get started.

## Prerequisites

- Rust stable toolchain (minimum **1.85**) — install via [rustup](https://rustup.rs/)
- `rustfmt` and `clippy` components:
  ```
  rustup component add rustfmt clippy
  ```
- [`cocogitto`](https://docs.cocogitto.io/) for commit message validation:
  ```
  cargo install cocogitto
  ```

## Building

```
cargo build
```

## Testing

Run the full test suite, including property-based tests:

```
cargo test
```

Run a specific test file:

```
cargo test --test integration
cargo test --test prop
```

## Linting and formatting

All CI checks must pass before a PR is merged.  Run them locally with:

```
cargo fmt --check        # formatting
cargo clippy --all-targets  # lints (pedantic, zero warnings)
```

To auto-format:

```
cargo fmt
```

## Commit messages

This project enforces [Conventional Commits](https://www.conventionalcommits.org/).
Every commit message must follow the form:

```
<type>(<optional scope>): <short description>

[optional body]

[optional footer(s)]
```

Common types:

| Type | When to use |
|---|---|
| `feat` | A new feature |
| `fix` | A bug fix |
| `docs` | Documentation only |
| `test` | Adding or correcting tests |
| `chore` | Tooling, CI, dependencies |
| `refactor` | Code change that is neither a fix nor a feature |
| `perf` | Performance improvement |

The CI pipeline runs `cog check` on every push and will reject non-conforming
commit messages.  You can validate locally before pushing:

```
cog check
```

## Submitting a pull request

1. Fork the repository and create a branch from `main`.
2. Make your changes, following the guidelines above.
3. Ensure `cargo test`, `cargo clippy --all-targets`, and `cargo fmt --check`
   all pass.
4. Open a pull request against `main` and fill in the PR template.

## Releasing

Releases are managed by maintainers.  The easiest path is the `just release`
recipe, which runs all pre-flight checks and then automates every step:

Releases use a two-step process to work with branch protection on `main`:

**Step 1** — open a release PR:

```
just release
```

This will:
1. Verify you are on `main`, the tree is clean, and not behind `origin/main`.
2. Run `cargo test`, `cargo fmt --check`, and `cargo clippy`.
3. Determine the next semver version from the commit history using `cog bump --auto --dry-run`.
4. Create a `release/vX.Y.Z` branch, run `cog bump --auto` on it (updates `Cargo.toml`,
   generates `CHANGELOG.md`, commits, and creates the annotated tag **locally**).
5. Push the branch and open a pull request against `main`.

Review the PR (check the generated `CHANGELOG.md` and version bump), then merge it normally.

**Step 2** — publish by pushing the tag:

```
just push-tag
```

Run this after the PR is merged. It pushes the local tag created in step 1, which
triggers the CI release workflow that publishes to crates.io and creates the GitHub release.

Breaking changes (anything that changes the public API) require a
`BREAKING CHANGE:` footer in the commit body so that `cog bump` can correctly
determine the next semver version.