Prepare for Satpy 1.0

[djhoese]

People at the Pytroll User Days suggested that we release a Satpy 1.0 sooner rather than later. This would help users justify using Satpy in operational settings (ex. "see it's stable"). We currently have a 1.0 milestone:

https://github.com/pytroll/satpy/milestone/7

But I'd like this issue to be a brainstorm/discussion about what else could or should be set for 1.0. On the day of writing this we just had our monthly pytroll meeting and a couple things came up that are backwards compatibility breaking enough that they could go in a 1.0 release:

Enhancement changes

1. Change default enhancement to a linear/null/error function. Suggestions that were brought up in the meeting today was keeping the linear min/max default enhancement for single band data, do a no-op null enhancement for multi-band composites that are uint8, but otherwise raise an error. An alternative to the error could be a warning and then the min/max enhancement. Related: https://github.com/pytroll/satpy/pull/817
2. Change default brightness temperature enhancement: How many people like dark clouds and how many like light clouds? The current default produces dark clouds.
3. Change default reflectance enhancement: The current default was a compromise between me and @mraspaud if I remember correctly. I wanted gamma 2.0 for a square root operation, but I believe Martin (and @pnuu) use a linear stretch (dynamic min/max or static crude?). Is gamma 1.5 really the best default?

What other ideas do people have, not just enhancement changes?

Reader changes

1. Remove readers that have been marked as "Defunct" for "some time".

[djhoese]

Another possible breaking change (slightly): https://github.com/pytroll/satpy/issues/789

[djhoese]

One thing that was discussed in the monthly meeting today that might be good for 1.0 or might be too much, would be restructured or adding to the ability to specify enhancements for different datasets. The overall issue is that mapping what enhancement is used for a particular composite is relatively difficult because of how many YAML files there are and how the enhancements are defined (generic standard_name versus name-specific ones versus all the other ways). Sometimes it might be nice to define the enhancement on the composite itself (full enhancement definition similar to enhancement YAML files) or use a name of an enhancement in the composite definition that points to an enhancement defined in the enhancement YAML files. It was also discussed how the GeoIPS project structures things per-product with information on what data source provides the data, what variable from that data source, how that data is resampled, and what enhancements are applied, all in a single definition.

What the "best" solution is was not really determined, but we pointed out that there are "cons" to all solutions we thought of so far.

Redefining or restructuring all of this and how standard_name is used to connect datasets to their enhancement may be too much for a 1.0 release and may have to wait for a 2.0 release.

[gerritholl]

I've added https://github.com/pytroll/satpy/issues/52 / https://github.com/pytroll/satpy/issues/536 (which are pretty much duplicates) to the v1.0 milestone. Some of my colleagues appear somewhat shocked that, in satpy, we can load data with sc.load(["vis_06"], calibration="reflectance"), which is returned with a standard name toa_bidirectional_reflectance, but which is not a reflectance. This problem has been known for more than seven years and should IMO be fixed by the latest with v1.0.

[BENR0]

I would like to have fixes for https://github.com/pytroll/satpy/pull/2332 and https://github.com/pytroll/satpy/issues/2331 included. Probably these are not that common of a problem that users stumble about it a lot but I think these are quite serious "bugs" that should somehow be fixed in a v1.0 .

[BENR0]

A quick write up of the possible road map regarding the improvement of the reflectance calibration issue according to a discussion with @mraspaud and @gerritholl on the last day of the PCW.

1. Agree on name for new calibration -> Slack Poll (@mraspaud)
2. Check all readers what calibration and modification is done by default and in accordance with what is done include a deprecation warning that in the future this is going to change what is actually returned by requesting reflectance calibration.
3. Come up with a documentation for developers listing the steps for migrating readers to the "new calibration".
4. Possibly release a v1.0 even though not all readers a migrated.

[gerritholl]

2. Change default brightness temperature enhancement: How many people like dark clouds and how many like light clouds? The current default produces dark clouds

This is sufficiently controversial to needs its own issue.

[gerritholl]

For all standard composites, change the name to the one recommended by the RGB guide produced at the 2025 RGB workshop. Remove aliases and confusables. Add a marker to indicate standard or not.

[djhoese]

Along the lines of the idea of a marker for indicated standard or not, and maybe we already have the means for this with "description" or the references, but identify the "defining" organization. We could theoretically then update the RGB if the organization who maintains the recipe updates it or decides that it needs to be refined for a specific sensor.

[loreclem]

Outcomes of the discussion at the PCW in Locarno (14th May 2025):

• We head for v1.0 (target date around September 2025, for example): satpy is mature and stable enough to be used operationally in various NMSs. The major release 1.0 reflects the fact that satpy is good and stable enough for many applications, even though not all the wishes are implemented and not all issues are closed.
• Exact release date to be decided at the upcoming community meeting (3rd June 2025)
• Also to be discussed at the community meeting: do we need a release candidate and - if yes - when shall this be released?
• In the future, we might have a regular major release (e.g. every year or two in autumn? to be discussed)
• Open issues for v1.0 that aren't closed for the official release date will automatically be transferred to the v2.0 release milestone
• Major releases would help in removing some deprecations, this should be handled with care
• The v1.0 release will be duly communicated through Pytroll's channels (Slack, mailing list, etc)
• If someone wants to volunteer for resuming Pytroll's presence on the social media (e.g. Mastodon, Blue Sky, Facebook?, X?,..) please step forward

Other topics discussed were the possibility to have long term support releases and to support older versions of Python for longer: due to the small amount of developers who can dedicate time to these activities, both options seem difficult to implement in practice.

[djhoese]

In the future, we might have a regular major release (e.g. every year or two in autumn? to be discussed)

This may have been said in the discussion, but if there aren't features/changes needing a major release then we shouldn't do a major release. We don't need people thinking that Satpy 2.0 is a big update when it is just that we hit our "deadline" for when we said we would do a major release. Semantic version number changes are based on code changes, not on a schedule.

[mraspaud]

In the future, we might have a regular major release (e.g. every year or two in autumn? to be discussed)

This may have been said in the discussion, but if there aren't features/changes needing a major release then we shouldn't do a major release. We don't need people thinking that Satpy 2.0 is a big update when it is just that we hit our "deadline" for when we said we would do a major release. Semantic version number changes are based on code changes, not on a schedule.

Yes, this was my understanding of the conversation we had.

[djhoese]

I just updated the original description to mention that some readers are marked as "Defunct". We should probably remove these from Satpy...right?

[BENR0]

I think it would be nice to keep the defunct readers around somehow if someone wants to work on them? But they probably should not be in the reader list. Maybe we can list them in the developer section somewhere?

[mraspaud]

We have a status field in the yaml file, could we use that?

[gerritholl]

This is sufficiently controversial to needs its own issue.

https://github.com/pytroll/satpy/issues/3238

[BENR0]

We have a status field in the yaml file, could we use that?

Yes thats what I am thinking. Just filter out all defunct readers for the reader table. And then if desired create a similar table with all the defunct readers in the dev section?