Page Comparison

Sunflower OST

• Node 22 is the version we want to use for Sunflower.
  • Node 22 is expected to become LTS in October 2024.  It's technically available now, but we might want to wait until it becomes LTS.  This isn't expected to be a problem.
  • NOTE:  really only impacts DevOps / SysOps
• Yarn 1 shouldn't change for Sunflower.  
  • Stripes Architecture is looking at where to go with this, but it's still not clear enough to make a decision for Sunflower, so for now stick with the status quo.
  • NOTE:  really only impacts DevOps / SysOps
• Stripes 10 or greater is the version for Sunflower.
  • This is a breaking change, and will "prune a lot of cruft"
  • Not released yet, stay tuned.  The release will be announced in the usual places (#stripes-updates, #releases)
• React 18.2 is the version for Sunflower.
  • 19.0 is not released yet, and it isn't clear when it will be.
  • Zak Burke will look into React's support policy for future reference.
• RTL 14 or greater is the version for Sunflower
• Java/JDK 17 vs 21
  • May still be stuck on this waiting on input from DevOps.
    • Conflicting information from Julian Ladisch and Jenn Colt on this.
  • Potential gotchas here with Spring and Keycloak.
    • Marc Johnson - Eureka hasn't been officially approved by Folio, so Keycloak isn't relevant here
    • The OST pages will need other changes if/when Eureka is approved.
    • Spring 3.4 only requires 17, but supports 21.  It's expected that the next version of spring will required 21.
  • Maybe we make Sunflower a transition release, where either 17 or 21 could be used.  We'd then be fully on 21 in Trillium.
    • This is contingent on DevOps being able to do the necessary work to support Java 21 in build infrastructure.
    • Supporting both is more work for things like security checking
  • Given that this isn't expected to have a significant impact on devs,  Maybe it's ok to wait for a definitive answer from DevOps, then make a decision in a week or two.
• MinIO/S3
  • "Any version compatible with the latest/current version of S3"
• Do we transition this from DRAFT → ACCEPTED, or wait until the TBD (Java) is sorted out?
  • Aim for making a decision on Oct 16 (or earlier)
  • Jenn Colt / Craig McNally will continue to push DevOps for an answer on this.

We did not get to this topic today.

We know that a project of this size is faced with architectural decisions of various sizes, ranging from things scoped very narrowly, which impact only one or a few modules/teams, to platform-wide decisions impacting almost everyone.  A one-size-fits all approach to making these decisions is unlikely to work well, and we've seen this already with the RFC process.  Let's enumerate the types/sizes of decisions we make, then try to identify the applicable processes for each.  If there are gaps, do we need to define additional processes or guidance for dev teams, and architects?

Types/sizes of technical decisions

• Team/Module-specific 
  • Process:  ad-hoc/team-specific, sometimes with the help of SAs
  • Who:  typically make internally by dev teams
  • Example(s): 
    • Whether certain functionality is added to an existing module, or to a new module.
    • Technology choices - shared libraries, frameworks, etc., e.g. quartz timers, various npm packages
    • Storage layout, e.g. jsonb vs traditional relational tables, etc.
• Problem-specific (needs to be defined better)
  • Process:
  • Who:
  • Example(s):
    • Pub-sub/Event-driven communications 
    • Adoption of spring-way
• Security-driven
  • Process:
  • Who:  Security Team
  • Example(s):
    • ...
• Platform-level/Fundamental
  • Process: RFC process
  • Who: Technical Council
  • Example(s):
    • Eureka
    • Consortia support (ECS) and cross-tenant requests (possibly problem-specific)
• UI architectural decisions
  • Process: A proposal or problem is brought to stripes-architecture, it's discussed, and a decision is made.
  • Who: Attendees of the stripes-architecture meeting
  • Example(s):
    • How GitHub actions are organized/implemented/used
    • Migration away from Yarn v1
• Module inclusion into a release
  • Process: TCR process
  • Who: Technical Council
  • Example(s): ...
• Officially Supported Technologies
  • Processes: 
    • Delegation to other groups/teams (e.g. stripes-architecture, security team)
    • Discussion with stakeholders, esp. those for whom there are work/effort implications (e.g. DevOps, developers)
    • Technical Council dedicated discussion
  • Who:  Technical Council w/ input from other groups
  • Examples: ... 

Existing Processes

• RFC process
• Officially Supported Technologies (OST)
• Decision Records
  • We have used this in the past as a decision making process, but more recently have used it only as a centralized log of decisions made via some other process, e.g. RFCs, etc.
• New module technical evaluations (TCR)
• Ad-hoc
  • Example:  module descriptor validation & fixes
• Team-specific 
• Delegation to other groups/teams
  • e.g. stripes-architecture, security team, etc.
• Technical Council dedicated discussion