API forward compatibility

[BenWibking]

Is it possible to provide an API forward compatibility guarantee?

There is a lot of breakage in downstream codes. Is Parthenon mature enough / will be soon mature enough to freeze the existing APIs?

[Yurlungur]

IMO I think we're pretty close to a stability point, with the GMG stuff that Luke has been doing going in. That said I'm reluctant to make a complete stability guarantee, as I think that may box us in going forward. Perhaps there could be a compromise, like we start marking things for deprecation well in advance of breakage?

What broke recently?

[BenWibking]

The API for custom boundary conditions was the most recent thing that affected me.

[lroberts36]

I think that we aren't really at a point were we should guarantee stability of the interface. I tend to agree with Jonah that making this guarantee boxes us in, even though we should strive for maintaining a consistent interface when possible. I am also hesitant to impose more constraints on the development process (i.e. marking things as deprecated before making changes) because the review process is already somewhat slow as it is.

As an important example, the addition of non-cell centered fields required some changes to the interface that were in some cases hard to make backwards compatible. Since this hasn't really been used in downstream codes, I am hesitant to say that we should just fix the interface now. It seems likely that with downstream experience we may want to be able to change the interface if it becomes clear certain choices that were made become unwieldy, etc.

All that being said, I think this is something we should probably discuss at the next Parthenon sync as I am sure there are a variety of opinions. I guess that it may be important to think about when we will consider Parthenon more or less major feature complete, since that would seem to be a pre-requisite for fixing the interface.

[BenWibking]

I think there might be a more feasible intermediate option, which is to guarantee more stability for the more complete parts of the code, e.g. for the finite volume parts of Parthenon, while allowing breakage with less complete parts, e.g. particles, linear solvers, possibly others.

Other options might be to have a separate CHANGELOG for things that break downstream codes, and/or a doc page with the same information.

At least for me, there's a fairly high maintenance burden in carrying out production simulations for a project that lasts several months (or more) with the current level of code breakage, while also staying current with the develop branch for bugfixes.

[Yurlungur]

The API for custom boundary conditions was the most recent thing that affected me.

Oh yeah. I actually think there's improvements to be made sitll there before we wanna finalize that one...

Other options might be to have a separate CHANGELOG for things that break downstream codes, and/or a doc page with the same information.

This could be a good idea... Maybe we could have a bot that emails a list if a PR is marked as breaking?

At least for me, there's a fairly high maintenance burden in carrying out production simulations for a project that lasts several months (or more) with the current level of code breakage, while also staying current with the develop branch for bugfixes.

This is fair... Another option could be we could return to a split development model with more fixed releases. Actually I thought we planned to do that---with a release every month... what happened to that? (Maybe this is another thing we should have a bot do...)

[pgrete]

I think some part of the discussion is also related to AthenaPK not really having a release cycle (or CHANGELOG).
So potentially, this is something we can sort out internally independent of the general discussion (which now put on the tentative agenda of the next meeting as suggested).