|
| 1 | +# Rezoom.SQL developer notes |
| 2 | + |
| 3 | +Notes for working on this repo. |
| 4 | + |
| 5 | +## Repo layout assumption |
| 6 | + |
| 7 | +The dev workflow assumes you have this repo cloned alongside its sibling |
| 8 | +repos (most importantly [Rezoom](https://github.com/rspeele/Rezoom)) under a |
| 9 | +common parent directory. The parent's name doesn't matter, but the |
| 10 | +siblings need to be together. |
| 11 | + |
| 12 | +``` |
| 13 | +my-rezoom-source-code/ |
| 14 | + .localfeed/ (NuGet feed for in-progress dev packages) |
| 15 | + NuGet.config (configures .localfeed as a package source) |
| 16 | + Rezoom/ |
| 17 | + Rezoom.SQL/ (this repo) |
| 18 | + FParsec-Pipes/ |
| 19 | + LicenseToCIL/ |
| 20 | +``` |
| 21 | + |
| 22 | +You need a `NuGet.config` at the parent level so package restore finds |
| 23 | +`.localfeed` ahead of nuget.org: |
| 24 | + |
| 25 | +```xml |
| 26 | +<?xml version="1.0" encoding="utf-8"?> |
| 27 | +<configuration> |
| 28 | + <packageSources> |
| 29 | + <clear /> |
| 30 | + <add key="local" value=".localfeed" /> |
| 31 | + <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" /> |
| 32 | + </packageSources> |
| 33 | +</configuration> |
| 34 | +``` |
| 35 | + |
| 36 | +If you're only working on Rezoom.SQL and don't need to iterate on Rezoom, |
| 37 | +you can use the latest published Rezoom from nuget.org. If you're changing |
| 38 | +both, pack Rezoom into the same `.localfeed` first using whatever script that |
| 39 | +repo provides. |
| 40 | + |
| 41 | +## Why the unusual setup |
| 42 | + |
| 43 | +Rezoom.SQL has two artifacts that interact awkwardly during dev: |
| 44 | + |
| 45 | +- The **type provider** (`Rezoom.SQL.Provider`) is loaded by `fsc` at compile |
| 46 | + time, not at the consumer's runtime. To test a TP change, a project has to |
| 47 | + reference a NuGet-installed version of the provider, not a project-reference |
| 48 | + to its source. (Project references don't trigger the same TP loading path.) |
| 49 | + |
| 50 | +- The **TP user smoke tests** (in `src/TypeProviderUsers/`) exercise the TP |
| 51 | + exactly the way a consumer would — they `PackageReference` the wrapper |
| 52 | + meta-packages (e.g. `Rezoom.SQL.Provider.SQLite`) which transitively bring |
| 53 | + in `Rezoom.SQL.Provider`. So testing a TP change means packing your changes, |
| 54 | + then letting the TPUs restore the new package and rebuild. |
| 55 | + |
| 56 | +The local feed + version-bump dance encodes this. Run `build/pack-dev.ps1` |
| 57 | +after a Provider change; the TPUs (and any consumer in the repo) automatically |
| 58 | +restore the new version on their next build. |
| 59 | + |
| 60 | +## Versioning during dev |
| 61 | + |
| 62 | +All Rezoom.SQL packages share a single version. Two files compose it: |
| 63 | + |
| 64 | +- `version.props` (committed): `RezoomSqlVersion = 0.13.0`, represents the upcoming or |
| 65 | + current release version. Bumped only at actual releases. |
| 66 | +- `version.local.props` (gitignored): written by `pack-dev.ps1`, contains |
| 67 | + `RezoomSqlVersionSuffix = dev.N`. The combined version becomes |
| 68 | + `0.13.0-dev.N`. Bumped extremely frequently during development, every time we have to smoke-test the TPUs. |
| 69 | + |
| 70 | +Every package and consumer reads these via `Directory.Build.props`. Wrapper |
| 71 | +csprojs and TPU / demo fsprojs reference our packages as |
| 72 | +`Version="$(RezoomSqlPkgVersion)"`, which resolves to the current dev or |
| 73 | +release version automatically. |
| 74 | + |
| 75 | +## Scripts |
| 76 | + |
| 77 | +### `build/pack-dev.ps1` |
| 78 | + |
| 79 | +Bumps the dev counter (one above the highest existing prerelease in the local |
| 80 | +feed), writes `version.local.props`, packs all six packages. Run after any |
| 81 | +change you want the TPUs or demos to see. |
| 82 | + |
| 83 | +```powershell |
| 84 | +./build/pack-dev.ps1 |
| 85 | +``` |
| 86 | + |
| 87 | +Add `-NoPack` to bump the counter and write the suffix file without actually |
| 88 | +packing. This could be useful if you want consumers pointed at a specific dev version |
| 89 | +without rebuilding producers. |
| 90 | + |
| 91 | +### `build/pack-release.ps1` |
| 92 | + |
| 93 | +Deletes `version.local.props` so the build has no prerelease suffix, then |
| 94 | +packs all six packages at the release version. Errors out if the working |
| 95 | +tree is dirty (override with `-Force`). After it succeeds, tag and push: |
| 96 | + |
| 97 | +```powershell |
| 98 | +./build/pack-release.ps1 |
| 99 | +git tag v0.13.0 |
| 100 | +git push origin v0.13.0 |
| 101 | +``` |
| 102 | + |
| 103 | +Drop the `.nupkg`s into wherever your nuget.org push lives. |
| 104 | + |
| 105 | +### `src/TypeProviderUsers/test-tp-users.ps1` |
| 106 | + |
| 107 | +Runs `dotnet test` on both TPU projects. SQLite can make its own DB file, but Postgres auto- |
| 108 | +skips when no server is reachable. Either set up your local Postgres like mine, with an |
| 109 | +`rz` user and password `testtest`, or use `REZOOM_TPU_POSTGRES` to override the |
| 110 | +connection string. |
| 111 | + |
| 112 | +## Why the TPUs aren't in the main sln |
| 113 | + |
| 114 | +The TPUs reference the wrapper packages via NuGet, not via project reference. |
| 115 | +Putting them in the same sln as `Rezoom.SQL.Provider` is confusing: opening |
| 116 | +the sln in VS suggests project-ref semantics, but the TPUs actually consume |
| 117 | +whatever's currently packed into `.localfeed`. Changing Provider source |
| 118 | +without running `pack-dev.ps1` would silently leave the TPUs on the old |
| 119 | +version. |
| 120 | + |
| 121 | +They live as standalone fsprojs under `src/TypeProviderUsers/`. Open them |
| 122 | +individually (or via the test runner script) when you need to verify TP |
| 123 | +behavior end-to-end. |
| 124 | + |
| 125 | +## Edit-rebuild loop for TP work |
| 126 | + |
| 127 | +1. Edit something in `src/Rezoom.SQL.Provider/`, `Rezoom.SQL.Compiler/`, or |
| 128 | + `Rezoom.SQL.Mapping/`. |
| 129 | +2. Run `./build/pack-dev.ps1`. New version is `0.13.0-dev.<N+1>`. |
| 130 | +3. Run `./src/TypeProviderUsers/test-tp-users.ps1` (or `dotnet test` the specific one |
| 131 | + you care about). Restore picks up the new dev version automatically. |
| 132 | +4. Iterate. |
| 133 | + |
| 134 | +If something doesn't update as expected, the usual suspect is a stale entry |
| 135 | +in `~/.nuget/packages/<pkg>/<version>/`. `pack-dev.ps1` clears those for the |
| 136 | +version it's about to publish, but if you manually pack something else into |
| 137 | +the feed, you may need to clear by hand. |
| 138 | + |
| 139 | +## Release flow |
| 140 | + |
| 141 | +1. Update `RezoomSqlVersion` in `version.props` for the new release. |
| 142 | +2. Update `<PackageReleaseNotes>` in the relevant csprojs/fsprojs. |
| 143 | +3. Update `CHANGELOG.md` (when one exists) and any docs that mention versions. |
| 144 | +4. Commit. Working tree should be clean. |
| 145 | +5. Run `./build/pack-release.ps1`. Verify the resulting `.nupkg`s in the feed. |
| 146 | +6. Push to nuget.org via your usual mechanism. |
| 147 | +7. Tag `v<version>` and push the tag. |
0 commit comments