2024-03-06 - Officially Supported Technologies

Jeremy Huff is next, followed by Marc Johnson

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. 

Goal:  Move the Ramsons OST page from ACCEPTED → ACTIVE.  Our (self-imposed) deadline for this is 15 Mar 2024 

• Review comments
• Add/remove/change versions as needed (focus on 1st party dependencies)

Notes:

• Craig McNally reviewed the topic at hand
• For the front end first part frameworks, stripes version 9.0.0 was discussed. Zak_Burke was contacted by Craig McNally via chat to confirm that this was the latest version of stripes. 
• For the back end first part frameworks there are quite a few more, and Craig McNally posed the question of how we should determine the appropriate versions for each release. Jeremy Huff responded that he typically just attempts to use the latest compatible version.
• Craig McNally then confirmed that the Q release required folio-spring-base 8.0 and that it existed (In response to Jeremy Huff's question), and it was concluded that 8.1 is likely to be the correct version for the R release.
• Zak_Burke responded to the question concerning the appropriate version of stripes that 9.2.0 was available, and that version was selected for the R release.
• Taras Spashchenko was asked to confirm the appropriate version for folio-spring-support, and replied that it would be "at least" 8.1.0
• Craig McNally observed that this was similar to the answer which Zak_Burke gave concerning Stripes, and that this can be challenging because of the lack of specificity
• Marc Johnson suggested that we skip the first party versions, because no one can be certain about the relevant version and should focus instead on third party dependencies.
• Craig McNally point out that the Q release timeline we attempted to nail down both 3rd and 1st part dependencies at the acceptance deadline so that teams can get started on the next version asap.
• Marc Johnson pointed out that the API freeze for platform is the point where most people make their version decisions
• Craig McNally part of the reasons we put together the OST page was for new module reviews, and that if we wait for the API freeze, there is not time to submit a new module.
• Marc Johnson agrees that this is impossible
• Craig McNally asks if it even makes sense to define versions for first part dependencies
• Jeremy Huff states that minimum versions seems like a good idea and can be defined earlier. This might help us safeguard  against very old versions being used
• Marc Johnson agrees that we could do that, but points out that this will result in the previous version being chosen each time. He can support the idea of just using the latest release as a minimum requirement
• Craig McNally defines 1st vs 3rd, and reviews our process
• Ingolf Kuss raised an issue with he selected version of  Open API, and suggested that 3.1 would be a better version
• Marc Johnson said that we have created an issue for ourselves with being overly specific about versions. He suggest that we could use 3.*
• Craig McNally added the language "or greater" to the version expressed in the document
• Marc Johnson felt that this helped him understand the purpose for changing these at this time, and supported the "or greater" language
• The subsequent versions were confirmed, and the "or greater" language was added.
• The OST page for the R release was moved to active
• Jeremy Huff observed that sonarqube does not support groovy, and there is a contradictions between the OST requirements and the acceptance criteria
• Craig McNally observes that the only thing that can be done about this on the OST page is to remove groovy. Jeremy Huff did no support that action. Craig McNally observes that this is a challenge with FOLIO being a polyglot
• Jeremy Huff stated that static code analysis could be provided by module developers in situations where their technologies are incompatible with the static code analysis techniques provided by the community.
• Marc Johnson there have been conversations about making the criteria more general in expressing the need for a "language appropriate static analysis" tool
• Jeremy Huff maybe a middle ground would be to add a section to the OST for static code analysis tools
• Craig McNally if the module developers provide those tools, then they will have control over the configuration of that tool, and might create lax standards for themselves
• Jeremy Huff suggested that maybe the TC might publish a general recommended configuration for static code analysis
• Craig McNally reviewed the meeting up to that point. He observed that since the first party dependencies imply specific versions of the third party dependencies, defining versions for both is a little redundant
• Marc Johnson states that the way out of this is to decide where we are going to be less specific
• Craig McNally recapped the history of the OST technology page and how it came to the level of specificity. He suggested that maybe we can simplify it by allowing it to just serve the purpose of module evaluation
• Jeremy Huff stated his support for simplification, but suggested that discussion would be needed
• Craig McNally suggested that some people would not be in favor of simplification of the OST
• Ingolf Kuss said he is in favor of a more general description as opposed to the more specific expression of version
• Marc Johnson said he is all for simplification and less bureaucracy. If he had known how this was going to be used he would not have been in favor of adding it. Some of the things that might be removed from the OST may need to find another home. We also may need to embrace the idea that some tools need to be proscribed. He also agrees that there will be push back, since the OST is being used for other purposes