Criteria and workflow for major changes and additions about icepyx HOT 1 CLOSED

Thanks for starting this critical conversation, @fspaolo!

Some of these points are addressed to an extent in the icepyx Development Plan, and I'll also respond here.

Right now, icepyx is young enough that it has not yet had a non-developmental release. According to the PEP440 Versioning Standards, we can make major changes to the API through until we release a version >0 (which we have not yet done. All of the current releases are still considered pre-releases and have version < 0). After that time, major API changes that are not backwards compatible would require version increments in the ones digit. Following best practices, I have also included warnings when major changes were made (so if you check out icepyx.core.icesat2data in the renaming branch, it simply contains an Icest2Data class with a DepricationWarning to let users know about the switch).

I have not yet heard any suggestions that I think are out of line with the goals/strategy/approach of icepyx or that use any non-stable libraries, so I'm thinking the best approach might be to address these questions as they arise. The pace of change in software development is staggering, so it can be hard to say what will or won't stick around.

You're right to point out that there's a fine line between proven practices and what "seems" best. icepyx tries to bridge that gap by enabling the user to interact with the data in multiple ways, using lower level manipulations under the hood but without the steep learning curve that many data manipulations require. For me, icepyx provides a high level wrapper for ICESat-2 data interactions just like fiona and shapely and geopandas provide great wrappers to gdal and ogr (which is what I learned to use because these other tools weren't widely used yet!).

from icepyx.