Have 8.0 in the Fall?

[Marten van Kerkwijk]

Hi All,

Since there were not many API changes in play, it seemed we were heading
for a release of 7.2 for the Fall. However, in the last month a couple
of PRs have appeared that do imply (minor) API changes, so I would
suggest that we do a 8.0 release instead (effectively, sticking to the
near-major-release in the Fall that has happened organically the last
few years).

In particular, having a 8.0 that would allow merging the following
already approved PRs,

- https://github.com/astropy/astropy/pull/18407 - which makes the
CODATA 2022 physical constants the default (we don't really want to
have those out-of-date ...)

- https://github.com/astropy/astropy/pull/18362 - which changes the
attribute used for velocities in coordinates from
DifferentialAttribute to CartesianAttribute as a way to solve a bug
(and make the code more logical, at the cost of a minor API change).

Furthermore, Pey Lian mentioned that she had a few more small things she
would want to get in if we were to have a new major release.

While the above are small, I think it makes most sense to just have a
next major release. Is there anything against doing that?

All the best,

Marten

[Pey Lian Lim]

Thanks for posting this, Marten!

To see all issues/PRs milestoned to v8.0, please visit https://github.com/astropy/astropy/issues?q=is%3Aopen%20milestone%3A%22v8.0.0%22

If I knew it was going to be v8.0, perhaps I should have upgraded PendingDeprecationWarning straight to DeprecationWarning in https://github.com/astropy/astropy/pull/17874 ?

What do you all think? We should make that call soon (v7.2 vs v8.0) so downstream has time to adjust.

[Clément Robert]

As far as I can tell, I see no strong argument against it. I generally think we could try to make breaking releases small and/or rare, but these changes seem necessary so I'd rather see them land in a small release.

Although not *intended* as (or known to be) breaking, patches that went into closing https://github.com/astropy/astropy/issues/18163 collectively consistute a minor risk of a breaking something downstream. In particular, it's possible, although unlikely, that regressions happen, be it in as memory leaks or degraded performance, so I'd feel marginally more confortable if they landed in a major release.

Clément

[Pey Lian Lim]

Who is the next release manager -- Tom R or Simon C? Maybe they can make this call? Thanks, all.

[hamogu]

We discussed this in the dev telecon today. While only five people where present, at least the five of use agreed that it would be best to stick to 7.2 in the fall and make an 8.0 release in the spring. In particular looking at https://github.com/astropy/astropy/issues/17864 this gives people several months to set the new `strip_spaces` option before the default changes.

Also, several people raised that they did not even think about PRs that might break API because they expected the next release to be 7.2. If we now decide that the fall release will be a major release, there is very little time left to suggest any API breaking PRs - and that's exactly the opposite of what we want: We want anything that potentially breaks the API to go into main as early as possible, not right before a release.

[Pey Lian Lim]

That sounds reasonable. Thanks for the update, Moritz!

[Marten van Kerkwijk]

I'm sorry I was unable to make the meeting in the end. I can see the
point of the conclusion, though would add that we are hardly "right
before a release" -- there *are* currently still several months before
the next one!

Also, the very reason that 7.2 made sense for a while -- that no API
changes seemed forthcoming -- also implies that there are not that many
worries about 8.0 breakage: I cannot really judge how big a deal
`strip_spaces` is, but the other API-changing PRs on hold hardly make
for great worries. Indeed, just not that much happened this cycle: the
what's new is currently empty. It may end up containing Tom's new ECSV
reader, though only if we don't make it the default (i.e., go against
the advise of the reviewers), otherwise it will be stuck in limbo too.

Note that sticking with no API changes for such a long time also comes
with a cost: since we don't have a branch in which things can get
merged, we just are stuck with increasing numbers of PRs that are done
but cannot be merged. This causes extra work (rebasing, etc.), and
holds up follow-up work.

-- Marten

[Aldcroft, Tom]

On Fri, Aug 8, 2025 at 9:21 AM Marten van Kerkwijk <mh...@astro.utoronto.ca> wrote:

I'm sorry I was unable to make the meeting in the end.  I can see the
point of the conclusion, though would add that we are hardly "right
before a release" -- there *are* currently still several months before
the next one!

Also, the very reason that 7.2 made sense for a while -- that no API
changes seemed forthcoming -- also implies that there are not that many
worries about 8.0 breakage: I cannot really judge how big a deal
`strip_spaces` is

The `strip_spaces` default change is a significant deal. There is a telemetry processing script for mission-critical Chandra operations that now requires `strip_spaces=False`. This is at the core of a 300 Gb data store that has been used in operations for  ~15 years.  It would have been better if fitsio originally stripped spaces, but now this is baked into our systems. As a specific example, some FITS files we use have the strings "ON " and "OFF". You will find code like `mask = vals == "ON "` in operations.

So we really need a full release to accommodate this change in a controlled way. There may be other places where `strip_spaces` has an impact so we need to do an audit and test.

One option would be having 8.0 be the next release but waiting on the `strip_spaces` change until a year later with 9.0. That would be fine by me.

- Tom

 

--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/87qzxmeyot.fsf%40dolphin.astro.utoronto.ca.

[Homeier, Derek]

On 8 Aug 2025, at 3:21 pm, Marten van Kerkwijk <mh...@astro.utoronto.ca> wrote:
>
> Also, the very reason that 7.2 made sense for a while -- that no API
> changes seemed forthcoming -- also implies that there are not that many
> worries about 8.0 breakage: I cannot really judge how big a deal
> `strip_spaces` is, but the other API-changing PRs on hold hardly make
> for great worries. Indeed, just not that much happened this cycle: the
> what's new is currently empty. It may end up containing Tom's new ECSV
> reader, though only if we don't make it the default (i.e., go against
> the advise of the reviewers), otherwise it will be stuck in limbo too.

It is probably not stated very clearly in the notes, but as I remember it there was quite clear
consensus that, in the spirit of APE 2
“These [minor] releases should *minimize* any API changes and focus on adding new features.”
minor releases do not completely exclude API changes altogether; and the changes from the
new ECSV reader (new backend with io.ascii engine) would definitely qualify as minimal
in this sense, as results are identical in all known instances, and any yet to be found deviations
should be limited to rare corner cases.
Those considerations shifted general opinion in favour of a 7.2 release.

Cheers,
Derek

[Clément Robert]

> Note that sticking with no API changes for such a long time also comes
> with a cost: since we don't have a branch in which things can get
> merged, we just are stuck with increasing numbers of PRs that are done
> but cannot be merged.  This causes extra work (rebasing, etc.), and
> holds up follow-up work.

I proposed over the telecon that we could have a feature branch too, and allow breaking changes to be merged at any point in main, which would solve this problem. However, the additional complexity required was not met with great enthusiasm, let's say, and we collectively aggreed to leave this proposal in the hands of our release managers (which I'm doing now :) ).

--
You received this message because you are subscribed to a topic in the Google Groups "astropy-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/astropy-dev/YWMQNXR0Nck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to astropy-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/astropy-dev/3FDE81C4-F128-4C25-AA50-5F94F89B8EAB%40gwdg.de.

[hamogu]

One point we considered is that AP 21 says that there will be one year between major releases. So, if the next release was 8.0, we cannot change the default for `strip_spaces` in the spring, because the next API breaking release cannot happen before fall 2026.

[Pey Lian Lim]

Re -- feature branch... We used to have LTS branch (i.e., 2 different release branches to manage instead of 1). It was too much hassle with little benefit so we got rid of it. Let's not regress.

[Clément Robert]

an LTS is a very different beast, the way I see it; there's a commitment to keep it maintained over a long period of time. That's not true of a feature branch: it can simply be frozen when backporting to it becomes a hassle.

Though, I hear you, we wouldn't want to have backport branches for every non-breaking PR (which is the majority). So what if we instead had a branch dedicated to breaking changes ? Such a branch could take in unregular merges from main instead of granular backports, and would be a place where we can merge breaking stuff at any point. Any better ? 

[Pey Lian Lim]

I think the original question of having 8.0 in the Fall has been answered: No.

As for changing how we branch and backport, that might need a new APE akin to https://github.com/astropy/astropy-APEs/blob/main/APE21.rst . Ultimately the burden falls on release managers, so we must consider their availability carefully.