1 min | Scribe | All | @Craig McNally is next, followed by @Tod Olson 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. |
* | Officially supported technologies for Sunflower |
| Sunflower OST Node 22 is the version we want to use for Sunflower. 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. 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. 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 Do we transition this from DRAFT → ACCEPTED, or wait until the TBD (Java) is sorted out?
|
Alternative/related topic | Making architectural decisions of various scopes | All | 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) Security-driven Process: Who: Security Team Example(s):
Platform-level/Fundamental Process: RFC process Who: Technical Council Example(s):
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):
Module inclusion into a release Process: TCR process Who: Technical Council Example(s): ...
Officially Supported Technologies
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 Team-specific Delegation to other groups/teams Technical Council dedicated discussion
|