[v7] Veda-UI Version 7 Roadmap

[vgeorge]

Overview

This ticket is a starting point for discussion around the next major release. The idea is that v7 should be the place where we introduce the breaking changes that come with removing deprecated code and finalizing migrations (e.g. Collecticons, Devseed UI).

The goal is to have a clear spot to track items that must be addressed in a breaking version, while also leaving space for other tickets that make sense for a major release.

Initial Scope

• Complete Collecticons retirement (#1814)
• Reorganize folder structure (#1871)
• Remove deprecated components and import paths (e.g.
  • Connections Sections and Legacy Footer (refactor: Replace Collecticons in legacy footer and connections section #1890)
  • card/ExternalLinkFlag
  • catalog-legacy/
• Complete documentation website [v7] Documentation Improvements #1370
• Clean up Storybook by removing temporary comparison stories
• CMS? Plugins?

Next Steps

This list is intentionally minimal. Let’s discuss what else should be in scope for v7 when possible.

cc @aboydnw @AliceR @dzole0311 @sandrahoang686 @faustoperez @snmln @hanbyul-here

[aboydnw]

I'm not sure what the cutoff would be for a new major version on veda-ui. Maybe something from the Epics board?

The idea is that v7 should be the place where we introduce the breaking changes that come with removing deprecated code and finalizing migrations

Would this depend on migrating the Earthdata instance to a NextJS instance, pushing GHGC 2.0 to product (not our responsibility) and deprecating any legacy code?

CMS? Plugins?
Re: CMS, I don't think we will be making big changes in the near future for our CMS work, so we can probably rule that out.

Re: Plugins, I think we've probably broken out the components from E&A that we plan to break out for the NLDAS tool, would that work be included?

[vgeorge]

I don't think we can define a closed scope for v7 yet. Clearing Devseed UI and removing deprecated components seems a hard requirement. Plugins readiness might be shipped in v6 if it doesn't entail changing components APIs too much, which we will discuss on the workshop retro. Currently the next js instance is a standalone repository, but I think we would benefit from merging into this if we switch to a monorepo. Along with CMS work, which make sense to ship as version 7.

[aboydnw]

Based on our conversations during pod week, I propose that we transition veda-ui into maintenance mode, or at least not actively plan a v7 until further notice. Here is the short version of my rationale:

• We are seeing the different things within veda-ui be treated more independently than before. Tools, catalogs, and stories and used in different ways across the instances. Maybe it makes sense to not package all of these things under on repo in the future.
• We've already seen a pattern from GHGC where they have their own repo of E&A
• New tools are either being placed in their own repos (ex. Fire Event Explorer, GHGC custom tools) or will eventually be created using the plugin framework
• With the direction we've been discussing for eoViz, I imagine the reusable part will be less polished or opinionated than what we have in veda-ui, because we are already seeing the different instances want their own styles. Earth.gov, GHGC 2.0, and even our designs for the Earthdata instance are all very different.

This is obviously a non-technical view, and is just my gut feeling after pod week. Ultimately I see this as primarily an engineering decision. I'm just giving my opinion here to get us closer to a decision.

[vgeorge]

@aboydnw thanks for the write up. I think it makes sense to enter maintenance mode and don't engage on refactors/features when there isn't a clear need for them. All the items in the list above seem to fall under that category. I'll close this ticket, we can reopen it in the future if situation changes. (cc @ifsimicoded)