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: JuliaManifolds/ManifoldsBase.jl#211

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:

• Move GroupManifold interface to ManifoldsBase. ManifoldsBase.jl#84
• Mutating variants of metric-related functions #357
• the tangent space and functions more unified, i.e. provide default basis for local_metric functions and make the basis parameter hence optional Provide default basis for local_metric functions and make the basis parameter hence optional #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. Implement more generic distributions on Manifolds #57 ref. Move more packages to weak dependencies #693 ).
• Move the differentiation API to a separate package (#329 ?) (the package: https://github.com/JuliaManifolds/ManifoldDiff.jl )
• More comprehensive atlas/chart support (maybe).
• Inconsistency in invariant metrics #471
• Rename LinearAffineMetric to AffineInvariantMetric #527
• Add non-size-specializing variants of manifolds #625
• Rename Symplectic to SymplecticMatrices? #701
• Implement translate_diff and inv_diff for all groups (#679) #683

[kellertuer]

I would like to also have

• the tangent space and functions more unified, i.e. Provide default basis for local_metric functions and make the basis parameter hence optional #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.