Github releases not in sync with registered versions

[CarloLucibello]

Last registered version on the Registries is v0.12.0 while the last github release in this repo is v0.11.0.

As a side note, it would be nice to have a new release whenever a PR is merged since changes are low frequency

[pdeffebach]

Yes, sorry about that. I need to do more releases.

I'm sorry about the github releases not being in sync. I'll look for a way to sync them up.

[pdeffebach]

@CarloLucibello

Thinking about this more, I recalled that the reason we aren't making frequent release is that we are still pre-1.0. This means every release is technically breaking according to SemVer, and making lots of releases will cause compat issues.

The solution, I think, is to power ahead to 1.0 (will compile a roadmap soon) so we can do a more reasonable and faster release schedule.

[bkamins]

@pdeffebach - I think that for DataFramesMeta.jl doing more frequent releases is not a problem because:

1. it is a small package (so precompilation is fast)
2. it is mostly used interactively (so it is not often used as a dependency in another packages, but rather in end-user code, where users mostly install latest version anyway)

(btw. it is OK to do patch releases if needed as e.g. to fix the broadcasting bug you fixed)

[CarloLucibello]

Bumping the y in v0.x.y is totally fine for both bug fixes and new features. Reasonable compat bounds, ie. in the form DataFramesMeta = "0.x", won't be affected. Don't be afraid of releasing often, if people don't want to be bothered with frequent updates because of precompilation time they can just avoid updating!
Some packages I know like https://github.com/JuliaDiff/ChainRules.jl go to the extreme of requiring that each pR bumps the version and have a github action checking that.

[CarloLucibello]

Releases are in sync now.

[CarloLucibello]

Out of curiosity, which was the breaking change that lead to v0.13 being tagged instead of v0.12.1?

[pdeffebach]

We added a new feature, @distinct, and this merits a minor version bump. Because we are pre-1.0, all these are technically breaking. It's annoying, but won't happen when we get to 1.0.

[CarloLucibello]

my experience with any package in the julia ecosystem is that in pre-1.0 they just update the patch version when adding new features, which avoids unnecessary compact changes in dependents.
The only way by which the addition of a new symbol like @distinct could break someone's code is if the symbol is exported and it is exported also by another package, and if they are both using-imported, using pkgA, pkgB. Again, this is commonly judged as non-breaking.