Release 1.0.0

[adler-j]

Release 1.0.0

I feel that ODL has now come far enough for us to start planning a 1.0 release. This is for several reasons:

• The user-base has started to grow somewhat, and breaking changes etc are starting to become a problem.
• ODL is largely feature complete w.r.t the basic stuff you need for inverse problems.
• A 1.0 release signals that we're in some sense ready to face the world and no longer a small internal project.

Remaining issues

Before a proper 1.0 release, I personally feel that these issues remain to be solved (i.e. somehow closed)

• Add Figure Of Merits #1017 Figures of Merit
• Add support for tensorflow together with ODL #972 Tensorflow
• Tensor spaces, second try #861 Tensor spaces, along with followup issues:
  • Vector and tensor fields #342 Vector and tensor fields
  • ENH: add cupy tensor space #1231 GPU backend using cupy
  • Representing vector- and tensor-valued functions #908 Representing vector- and tensor-valued functions
  • Power spaces and tensors #857 Power spaces and tensors
  • Indexing of multi-dimensional spaces #965 Indexing of multi-dimensional spaces
  • asarray() for power spaces #83, Add asarray to ProductSpaceElement #1139, ENH: Add ProductSpaceElement.asarray, closes #1139 #1152 Power space shape, indexing and ProductSpaceElement.asarray()
• Add OperatorMeta #935 Add OperatorMeta (or decide against)
• Make adjoints, gradients etc. correct for weighted spaces #1068 Correct weighting of adjoints
• Rename solvers package and move functionals #944 Rename solvers package (with some deprecation mechanism?)
• Solvers API slightly inconsistent #1197 Solvers API unification
• Op repr updates #1394 DONTMERGE: improve repr by a lot #1276 Updates to __repr__
• Discrete convolution #1230 Convolution (*cough*)
• Split utility.py #1386 Split up utility.py
• WIP: Add vector geometries #1418 ASTRA vec geometries
• WIP: Issue 1323 optest #1334 Diagnostics overhaul
• (Gradually) add advanced interface to solvers #1400 Advanced interface to solvers (maybe?)
• Make TODO comments more specific and prune them #1311 A general cleanup of TODOs

Feel free to add more stuff to this list.

Release workflow

Since 1.0 is a major release that we'd hope to be stable, I propose that we first update ODL to 1.0.rc1, where rc1 means release candidate 1 and work with this for a short while in order to guarantee a good release.

Breaking changes after 1.0

I propose that we, after 1.0, try to allow at least one minor version between breaking changes, i.e. first add a warning and then later actually remove the feature. For obvious reasons we don't need to religiously follow this, but I feel that it would help more people use ODL.

Edit @kohr-h: Fixed FOM spelling
Edit2 @kohr-h: Added some more open PRs
Edit3 @kohr-h: Added ".0" to the title

[kohr-h]

Release workflow

Since 1.0 is a major release that we'd hope to be stable, I propose that we first update ODL to 1.0.rc1, where rc1 means release candidate 1 and work with this for a short while in order to guarantee a good release.

Sounds good.

Breaking changes after 1.0

I propose that we, after 1.0, try to allow at least one minor version between breaking changes, i.e. first add a warning and then later actually remove the feature. For obvious reasons we don't need to religiously follow this, but I feel that it would help more people use ODL.

I agree. At large I'd say that after 1.0 we need a Really Good Reason (TM) for breaking changes, at least in public APIs. Here I feel that in general, we could do a better job at differentiating between public and private APIs. For starters, anything that is not part of __all__ should be considered internal or implementation detail and thus not part of any API guarantee. We could make this more clear by putting underscores before all these guys.

[kohr-h]

I've made a project page to keep track of the status of the issues and PRs. It's a bit easier to keep an overview there.