search

SAFEHR-data / PIXL

PIXL Image eXtraction Laboratory
Apache License 2.0
8 stars 0 forks source link

Bump module versions to `v0.1.0` and create release #473

Closed milanmlft closed 3 months ago

milanmlft commented 3 months ago

This will be the version of PIXL that will be used for the PINPOINT project

mxochicale commented 3 months ago

Good call @milanmlft @stefpiatek on having v0.1.0 for pixl See https://github.com/UCLH-Foundry/PIXL/issues/427 as you might like to version control others package deps (pixl_cli, hasher, pixl_dcmd, etc) and think of a minimal release cycle (0.1.0-rc (1-month?) and 0.1.0, (6-months?), 0.2.0-rc (1-month?) and 0.2.0, (6-months?, etc), your choice on the time frames of the release cycle. Happy to help with the review when is ready

stefpiatek commented 3 months ago

I think it might be a bit premature optimisation to aim for a release schedule. AFAIK this is being used as a standalone deployment only at UCLH so we can decide on release when we feel like we've made substantial changes (basically follwing semver). We might have a point where we do no development for months and then a sudden burst where we want to make several minor releases for example

Up for having the next version as a release candidate after we've merged this into main and created a release & tagged on github though

milanmlft commented 3 months ago

What's the convention for Python packages to indicate a "development version"? Is it *.*.*-rc? Once we created the 0.1.0 release, I guess we then want to immediately bump all the versions to a development version (i.e. 0.1.0-rc for example)

stefpiatek commented 3 months ago

I think it'd be 0.2.0-rc because its a release candidate for the next release of 0.2.0, not to say that you can't then make a release off that one that is 0.1.1 if you decide you want to have a bug released, but I expect we're a way off from bugfix releases and instead we'd roll it into the rc