Breaking changes coming up in v2: Transition from ECS to Harmony for ordering and services

[mfisher87]

Milestone: https://github.com/icesat2py/icepyx/milestone/5

👋 Hi all,

The motivator for this change is that the ECS system is going offline. Unfortunately, icepyx v1 will eventually break because of this!

I'm beginning this work on a new v2 branch. I created a draft PR (#544) where you can keep up-to-date on that work. I'll be opening PRs targeting this v2 branch for increments of work for review.

I don't have a full understanding of all the breaking changes yet. For now, I understand that variable subsetting support will be dropped.

@weiji14 @JessicaS11 (anyone else that we should bring in?) How would y'all like to review this work as I go? Would you like to review each PR, or review the main v2 draft PR at the end? I can continue the practice of squash-merging so that PR can be reviewed commit-by-commit if we decide to go with the latter. I would also plan to use rebase to keep that branch up-to-date with development, also for reviewability. Thoughts?

[JessicaS11]

My thought is to treat the v2 branch as a second development (i.e. feature) branch, and enforce a similar set of rules (squash-merges, no direct commits (only PRs with review), CI, etc. That way we can simply merge (NOT squash merge) v2 into development and then main when it's time to release v2 but will have all the reviewed PRs from the incremental review steps (rather than an overwhelming PR).

I would also plan to use rebase to keep that branch up-to-date with development, also for reviewability
Sounds good.

[mfisher87]

Can you think of any important things that we will need to release in v1? If we can confidently make a "final" v1 release, we could simplify by working on v2 on the development branch, and if we need to do any v1 bugfixes, we can treat those as an exception and work on those on branches. I think this project is a good candidate for this approach because we won't have any need/ability to support v1 after the ECS shutdown, so we can plan to focus our efforts on a high quality v2.

[JessicaS11]

If we can confidently make a "final" v1 release, we could simplify by working on v2 on the development branch, and if we need to do any v1 bugfixes, we can treat those as an exception and work on those on branches.

I am happy to take this approach. I'd like to try and get some of (1) the hackweek updates, (2) our deprecation warning!, and (3) open PRs that streamline CI, etc. that are NOT breaking into another v1 release. Perhaps next week we can have a tagup to plan out a timeline for this work.

[mfisher87]

That sounds great. Maybe we could co-work for a bit to knock some of the release checklist off if that helps!