1.0 release planning

[mateuszbaran]

I'd like to collect in one place items that we'd like to do before releasing 1.0 of Manifolds.jl and ManifoldsBase.jl. I'm not going to specifically focus on these but I think it'd be nice to have some sort of a roadmap. Please feel free to propose changes, this is just a list of a few things that came to my mind.

ManifoldsBase.jl:

• [x] Solve https://github.com/JuliaManifolds/ManifoldsBase.jl/issues/88 . I would expect it to be only slightly breaking for any external codebase that relies on it.
• [ ] Rethink inverse retraction-based distance (ref. https://github.com/JuliaManifolds/Manopt.jl/pull/144 )
• [ ] Maybe rethink curve specification for vector transports along.

Now that we don't import all symbols exported by ManifoldsBase.jl to Manifolds.jl we can move things from Manifolds.jl to ManifoldsBase.jl without tagging a breaking release.

Manifolds.jl:

• [ ] https://github.com/JuliaManifolds/ManifoldsBase.jl/pull/84
• [ ] JuliaManifolds/Manifolds.jl#357
• [ ] the tangent space and functions more unified, i.e. provide default basis for local_metric functions and make the basis parameter hence optional JuliaManifolds/Manifolds.jl#424 with the basis.
• [ ] Figuring out geodesics on metric manifolds (and polishing metric manifolds in general).
• [ ] Move distributions of manifolds to a separate package (ref. JuliaManifolds/Manifolds.jl#57 ref. #693 ).
• [x] Move the differentiation API to a separate package (#329 ?) (the package: https://github.com/JuliaManifolds/ManifoldDiff.jl )
• [ ] More comprehensive atlas/chart support (maybe).
• [ ] JuliaManifolds/Manifolds.jl#471
• [x] JuliaManifolds/Manifolds.jl#527
• [x] JuliaManifolds/Manifolds.jl#625
• [ ] #701
• [ ] #683

[kellertuer]

I would like to also have

• [ ] the tangent space and functions more unified, i.e. JuliaManifolds/Manifolds.jl#424 with the basis.

But overall I think our interface is stable enough (after the changes you proposed already) to go towards a 1.0, yes. I will check whether there is a specific feature we might want to support for manifolds in general.

[mateuszbaran]

Sure, I've added it to the list. Metric manifold stuff seems to be the least mature part of our interface.

Regarding additional features, there is still quite a lot that could be added, and I haven't even documented everything in issues yet.

[kellertuer]

Let's maybe collect a few features that we might want to have for a stable 1.0 release, though we have more open issues by this approach.

Concerning the metric manifold ideas, I can look into that but I first wanted to consider Hessians.

[mateuszbaran]

Concerning the metric manifold ideas, I can look into that but I first wanted to consider Hessians.

Sure, Hessians would be a nice addition for Manopt.jl. Concerning metric manifolds, I'd suggest mainly focusing on working in charts.

[sethaxen]

I don't think we need to rush to a 1.0. It implies an extreme stability and is quite limiting when it comes to making changes. In particular, I would like to see the interface battle tested by a large variety of packages before considering this. If packages aren't using it, there's no need for a 1.0. And if they are, and we're finding the interface needs no changes, then we can consider it.

A roadmap in general is a good idea though.

[kellertuer]

You are right, we should definitely not rush and there might be changes coming when the package is used more and we should not rush to a 1.0 before the “battle testing” has happened to some extend.

I think the idea here is exactly to collect points and features towards a 1.0.

[mateuszbaran]

Yes, exactly, I don't want to rush 1.0 but just have a place to discuss what breaking changes are planned.

[kellertuer]

I was looking around a bit whether we can reduce our issues a bit by solving the easier ones at least. I would add one point to the list before w go 1.0

• [ ] Decide whether the abstract types should have abstract in their names

We currently have that somewhere introduced (for Manifolds for example), but the more I see those names they feel like they have their type in their name, which I do like less and less. But my main point is, we are not consistent. So we should check that and aim for a consistent naming scheme (where I would prefer to avoid AbstractX names, by now though I might have introduced a few of them myself).

[mateuszbaran]

Hm, I actually somewhat like the AbstractX names. When I see a method f(::AbstractType) I can quickly see if it dispatches on abstract or concrete type. But I can definitely live without that.

[kellertuer]

While I have a slight tendency towards not having that, I see mine as just a personal feeling, so if you have a reason that simplifies your workflow, we can go with your idea as well; I think my main argument was more to then unify that throughout the packages.

I just feel sometimes it is a bit clumsy and yields long names with the Abstract upfront and usually the docs (for me on mouse hover) tell the type (whether its abstract or not) anyways real quick.