Tag v1

[dlfivefifty]

It's been 2 years without a breaking change, we might as well tag v1

[daanhb]

Not against moving to v1, but just pointing out that I had some breaking changes lined up for v0.8: #171

The pull request lists what's changing. I think we should do this before v1.

[dlfivefifty]

We can just make v0.8 v1?

[daanhb]

Sure, we could do that. I can work on it, but not just yet - later in October.

One thing that stopped me from releasing 0.8 I think was that there was no smooth transition path. As in: how can you in another package safely use either one of DomainSets 0.7 or 0.8 (or 1.0)? It would take a long time for everyone to switch if you had to actively choose between them. If we can make it smoother, then the "breaking" changes really aren't that breaking.
A lot of symbols are no longer exported, because FunctionMaps moved out. Perhaps it is just a matter of writing all the deprecations.

[dlfivefifty]

The “right” thing to do is release v0.8 with a bunch of deprecations and then v1 with the functionality removed

But whether it’s worth the extra burden is questionable

[daanhb]

I've updated the dh/0.8-breaking branch and remembered something relevant.
-> v0.7 internally includes a FunctionMaps package.
-> In v0.8 I took it out, since FunctionMaps.jl now lives on its own as a registered package.
I don't know whether other packages could support DomainSets 0.7 and 0.8 at the same time. If they (even inadvertently) use maps functionality with v0.8, then they'd have to import FunctionMaps. However, if they do, and then somebody runs the package with DomainSets 0.7, the user has loaded two (different!) versions of FunctionMaps. That seems very undesirable.

The right update path might be to remove FunctionMaps.jl from the 0.7 series first in a non-breaking way, and only then to introduce the breaking 0.8 series. In that case the double-package issue can be avoided. Afterwards, we can declare 0.8 to be 1.0. Does that make sense?

[daanhb]

I've completed the "factoring out of FunctionMaps" in v0.7.17 (nov 0.7.18) as I saw a compatible way of doing so. Breaking changes went into 0.8. If this works out and remains stable for a while, we can make 0.8 version 1 later on.

I've checked some packages, though not all, that depend on DomainSets and they seemed to be fine. In my own packages I can put DomainSets = "0.7.18,0.8" in the requirements, and that means people can hopefully easily upgrade.