Reminder: Please copy/paste the Zoom chat into the notes. If you miss it, this is saved along with the meeting recording, but having it here has benefits.
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.
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?
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.