Bump major version in the next release

[ViralBShah]

With #297 merged, this is a reminder to bump the major version whenever we tag a new release, since we have a breaking change.

[devmotion]

If we don't want to make a new release right away, maybe we could follow ColPrac's suggestion and bump the version number to 2.0.0-DEV? I assume this would make it less likely that accidentally it's forgotten to bump the major version.

Or, maybe one could even view #297 as a bugfix that removed some type piracy (and seemed to affect only a single package)?

[ararslan]

FWIW I've never found the -DEV suffix to be a particularly useful convention; IMO it mostly adds overhead and commit noise.

Also, I don't think there's anything stopping us from just tagging a breaking release right now.

[ViralBShah]

Definitely should not treat it as a bugfix, because it will break code that depends on it. If there are a few other things we want to do for 2.0, we should wait for a few days. If nothing else is on the horizon, then we can just tag. There's no shortage of major version numbers, after all :-)

[ararslan]

I can't speak to what people have desired to put into the next breaking release version, though it's worth noting that this breaking change has been the only commit to master since the last release. That seems like a decent opportunity to make a new release, since it means there aren't lingering bugfixes on master that people are waiting for, so a new release wouldn't require them to upgrade their supported major version in order to get some particular fix. Plus we can always go back and make more releases prior to this breaking change if needed by backporting commits.

[KristofferC]

I just want to say this here as well that this was not a good idea at all (#361 (comment)). A tiny type-piracy fix is nothing of value compared to the extreme amount of work this causes downstream.

There's no shortage of major version numbers, after all :-)

That is not a good attitude to have when maintaining a library like this one that a lot of packages depend on. It's like saying we could just push out a Julia 2.0 tomorrow if we wanted with some small keyword change "because we have the major version number available". On this repo, it is changing one number from a 1 to a 2. For the ecosystem there are countless of CompatHelper PRs, countless of new registrations etc.

Plus we can always go back and make more releases prior to this breaking change if needed by backporting commits.

Yes, I think this should happen for quite some time and it would be very nice if the people that pushed for a new breaking release could take on some of the burden of this.