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: Add image 'mode' as identifying attribute to enhancements #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?

[djhoese]

Another possible breaking change (slightly): #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.