StructArrays v0.6 vs. v0.7?

[oschulz]

What's the plan with StructArrays v0.6 vs. v0.7? Will new non-breaking changes be released on v0.6, on v0.7 or on both? I just ask because I had already updated and patch-released a few packages to StructArrays v0.7 compat before the "revert" to v0.6.

[aplavin]

Idk, should we do anything else here other than proceeding as usual?
I did everything I can here – promptly fix the "breaking version" bump by releasing the corresponding 0.6.x, and ask the General registry maintainers to yank 0.7.0 so that to avoid confusion (JuliaRegistries/General#119607).
As 0.7 was presumably tagged without actual intent to have a breaking version, it's natural to just ignore that and continue with 0.6.x as things were going before.

The General maintainers said that there's no need to yank 0.7 – I was surprised by that response, but the registry state is fully up to them, not much we can do in that regard.

[oschulz]

Idk, should we do anything else here other than proceeding as usual?

If all future changes will be released as v0.7.x, and important stuff is backported to v0.6.x, then all is fine, I think. But if improvements go into v0.6.x but not into v0.7.x, then people who have updated the version bound in their packages to v0.7 (some have and CompatHelper will make sure many more do) will get outdated versions of StructArrays.

I'd vote for maintaining v0.7.x and v0.6.x in parallel for a a limited time, and then only maintain v0.7.x after the CompatHelper updates have propagated through the ecosystem.

[oschulz]

For example, I'm currently not getting #311 in several of my packages because it's only part of v0.6.21 (there is no v0.7.1). My packages were already released with v0.7 support before the "retraction". I also can't "downgrade" those packages and limit them to StructArrays v0.6 again - because then the package resolver has to decide between picking either the newer version of StructArrays or the newer version of my package, and it might decide in favor of StructArrays v0.7 ...

[ptiede]

I agree with @oschulz. I almost immediately updated all my packages to use StructArrays 0.7, and I cannot revert them anymore.

[sjdaines]

Also agree with @oschulz :
I'd vote for maintaining v0.7.x and v0.6.x in parallel for a a limited time, and then only maintain v0.7.x after the CompatHelper updates have propagated through the ecosystem.

If 0.7 exists and can't be yanked from the registry, then that has to contain the latest updates, and that will unfortunately result in unnecessary work updating compat for dependent packages...

[aplavin]

Don't think there's any dedicated maintainer for StructArrays, so any members of the org/repo are welcome to proceed however they see fit. I personally don't have experience with nonlinear histories in Julia packages, and don't know how exactly this

I'd vote for maintaining v0.7.x and v0.6.x in parallel for a a limited time

is done.

[oschulz]

I'd propose to merge the master branch with v0.7 and continue development on that basis, and create a branch release/0.6 and backport to it every time a new v0.7.x release is made. After three month or so we can then stop that, as most packages will have updated their version bounds to v0.7.

[oschulz]

I can help out, but I currently don't have write permissions on StructArrays.

[goerz]

This seems like a good solution, although I'm not sure that backporting to the release/0.6 is really that necessary. I'd maybe do it for serious bugfixes, but definitely not for new features (if you somehow keep track of which PRs are features and which are bugfixes, despite being pre-1.0). For a package that doesn't have a dedicated maintainer keeping up with two release branches seems like a lot of overhead. Personally, I'd just move on, and only develop off v0.7. But it's up to y'all how you want to manage releases and continued development.

To be clear: backporting as discussed here is extremely reasonably, and maybe the best way to deal with this particular situation. It's just more work than I'd be willing to take on, personally, if I was involved in maintaining this package.

[oschulz]

I'd be happy with v0.7.x-only as well.

[nhz2]

Changes can be backported to v0.6 without needing a separate branch if you want both identical.
For example, if the current versions are 0.7.x and 0.6.y and you want to do a release.

1. Make a commit changing the version in the Project.toml to 0.6.(y+1)
2. Register that commit
3. Make a commit changing the version in the Project.toml to 0.7.(x+1)
4. Register that commit

[oschulz]

I don't know if we constantly want to swap the package version on the master branch ;-)