Criteria and workflow for major changes and additions

[fspaolo]

Starting this thread for discussion on workflow and guidelines for major modifications to the package. Here are a few topics that came to mind when I started thinking on new feature implementations:

• How to proceed when a feature addition requires significant modifications to stable classes/methods/submodules?

• How to proceed when a new implementation changes/affects the overall strategy/approach used by the package?

• How to proceed regarding suggestions of, for example, new data structures, file formats and strategies that have not been extensively tested or adopted?

In particular I want to bring attention to the distinction between what "seems" in principle an optimal way to operate with the data, and what actually "gets the job done" in practice (based on experience and use cases).

[JessicaS11]

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!).