Release planning after 0.4.0

[sk1p]

• first, release libertem_blobfinder version 0.4.0 (that's where we start, right?) with dependency on `libertem>=0.4.0.dev0'
• then, in libertem master, add a dependency on libertem_blobfinder>=0.4.0 - WIP in Replace blobfinder with imports from libertem_blobfinder LiberTEM#585
• replace blobfinder code in libertem with imports from libertem_blobfinder w/ DeprecationWarning - WIP in Replace blobfinder with imports from libertem_blobfinder LiberTEM#585
• release libertem 0.4.0
• in libertem 0.7.0.dev0, remove dependency on libertem_blobfinder

Once this is done, the blobfinder code can evolve more freely, we can untangle the libertem-related functionality from the independent parts (see #5 for example)

[uellue]

Having parallel version numbers for all libertem-* packages is a good idea, by the way.

[sk1p]

Having parallel version numbers for all libertem-* packages is a good idea, by the way.

For the most part I would agree. Once we extract more of the utility packages, however, it may be a good idea to let those "run" a bit faster. The leaves in the dependency tree should move faster as not to block progress in their dependents. As an example, imagine you are adding a new mask-generating function to libertem-masks, to support a new UDF in some other libertem-foo package. If we keep the versions in sync, the change in libertem-foo would have to wait for the next round of releases.

[sk1p]

What do you think about postponing #8 and #13 until after the release? The documentation will be pushed continuously anyways...

[uellue]

I was just about to work on documentation. It would mostly be copy and paste from LiberTEM. I'd prefer to spend one or two hours on getting it towards a minimum viable state before releasing.

[sk1p]

Ok 👍

[sk1p]

Anything missing for RC? I think we are good to go!

[uellue]

I think so too. :-)

[uellue]

Once we extract more of the utility packages, however, it may be a good idea to let those "run" a bit faster. The leaves in the dependency tree should move faster as not to block progress in their dependents. As an example, imagine you are adding a new mask-generating function to libertem-masks, to support a new UDF in some other libertem-foo package. If we keep the versions in sync, the change in libertem-foo would have to wait for the next round of releases.

Good point! Since we are working on keeping a roughly monthly release cycle for main LiberTEM, we should be able to bring things back into sync in a timely manner. We'd perhaps have a week or two where the master branch of one package would depend on a development version of another. A bit similar to the current libertem_blobfinder situation.

[uellue]

Anything missing for RC? I think we are good to go!

Ah, I just remembered that we have to create a new record on Zenodo and update the record IDs! Otherwise we overwrite main LiberTEM. I'll take care of it!

[uellue]

create a new record on Zenodo and update the record IDs

Done, including settings for Travis. Sandbox parent is 494128, production parent is 3663437. Looking forward to test with a RC to confirm that it works as intended.

[sk1p]

blobfinder v0.4.0 released 🎉 🎉 - zenodo / github / pypi integration works fine.

One thing to think about - we may want to have semver-ish dependencies from libertem to the extracted packages - something like libertem-blobfinder>=0.4.0,<1 - that way, if we want to break the libertem-blobfinder interface, we can do so by doing a major release, without affecting older libertem versions.