How do we make tool version decisions? I’m asking because FOLIO is currently on Java 11. I imagine it could be prudent to move to 17 (the next LTS) at some point, and it seems that the#stripes-architecturegroup made the decision to move the project from Node 14 to 16 recently.I don’t think there is an equivalent group for the back end. How do we envisage the project making these kinds of decisions?
Some feedback was given, but it's probably worth discussing as a group.
Should we form a sub-group to define policies/processes?
there was some discussion and some comments; in general, the problem is relevant for the backend, frontend, and infrastructure. Agreed to make a placeholder for next week, and once again contact in search of volunteers
Make a page with the tools and versions for Morning Glory as a starting point.
Jeremy Huff : will we use ADR for answering questions like "What should receive long-term support?" Radhakrishnan Gopalakrishnan : still up for discussion. Marc Johnson : let's keep those separate; maybe there is confusion about the word "support", i.e. "supported technologies" vs "long term support for a given release".
Objectives: consistent use across teams, choose LTS versions, be timely WRT security issues, plan updates ahead of time
Julian Ladisch : there may be little/no benefit to enforcing consistency across backend modules given they are independent; Radhakrishnan Gopalakrishnan these are guidelines for an honor system; let's not get hung up on enforcement.
Olamide Kolawole would a non-java backend module be accepted today? Zak Burke given module acceptance criteria no. Group chat Ian Walls , Brooks Travis : this is unfortunate and may stifle community contribution.
Radhakrishnan Gopalakrishnan this has been left up for review, there were couple of comments. He is not sure if this is enough feedback. We will leave it open for more feedback.
Radhakrishnan Gopalakrishnan : this amounts to a support policy; Tod Olson : yeah, and also intersects with support policy recommendation that has been made; does the TC really get to make this decision for MG?
Mark Veksler : also looking for guidance from security group about when to do/not do security investigations ; LTS designation should be done by PC, not TC; there are cost implications. Guidance from PC was to revisit this in late 2022.
Julian Ladisch : security fixes need to be evaluated for criticality and how long they should be backported. Want a decision WRT how far back security issues should be backported?
Mark Veksler we don't have an LTS now, but have "current and previous" guidance and should stick to that for now.
Owen Stephens fixing security updates to a flower release, vs to the release of the component itself (stripes, raml, spring) seems awkward.
Ingolf Kuss : what feedback are you looking for from sysops? Julian Ladisch endorsement, which can come via lazy consensus
Craig McNally but is this our decision or the PC's? Marc Johnson but it's landed in our court for now. All: let's briefly discuss moving it forward next week.
Jeremy Huff : if not deciding about MG specifically, TC certainly can/should be involved in the general criteria for LTS designation.
Jeremy Huff Which versions are LTS should be decided by the PC and how we handle LTS should be handled by the TC
Marc Johnson The individuals who originated the proposal should put together a cross council group to address this
Zak Burke We should not make a decision that is specific to morning glory, but a general decision about LTS support
Julian Ladisch The LTS topic will take longer to discuss, this ADR was intended to get a quicker decision for morning glory
Zak Burke A longer and more generalizable discussion now will save us time in the future
Marc Johnson Agrees that we should have a policy concerning security back ports, but this may be something which should be managed by the POs (Oleksii Petrenko) and not the security group.
Tod Olson Whoever drives this forward should get in touch with those who wrote the LTS recommendation.