This approach may also require a rethinking of how we organize the repository (including tags); ideally we keep this as a monorepo, because that makes development much easier:
- For version management of
dial_dataclass and dial_service, we can always bump the dial_service version separately. If we need to bump the dial_dataclass version then we can have it "skip" some versions to catch back up to dial_service. For example, the following table shows an example where we want to push out a version of dial_service where we make no changes to dial_dataclass:
| dial_dataclass |
dial_service |
| 0.2.0 |
0.2.0 |
| 0.2.0 |
0.2.1 |
| 0.2.2 |
0.2.2 |
This means that we don't really have to change how CI/CD is set up, and we can have Git tags be representative of dial_service .
dial_dataclassanddial_service)pipcommands (UV only required for development team)dial_dataclassversion to PyPIdial_servicedial_dataclasspackage should ONLY have Pydantic as a dependency, all other dependencies i.e. INTERSECT-SDK should be specified ondial_serviceThis approach may also require a rethinking of how we organize the repository (including tags); ideally we keep this as a monorepo, because that makes development much easier:
dial_dataclassanddial_service, we can always bump thedial_serviceversion separately. If we need to bump thedial_dataclassversion then we can have it "skip" some versions to catch back up to dial_service. For example, the following table shows an example where we want to push out a version of dial_service where we make no changes to dial_dataclass:This means that we don't really have to change how CI/CD is set up, and we can have Git tags be representative of dial_service .