Marc Johnson explained in as Slack thread following distinction/definition:
FOLIO systems (the set of modules included) can be defined as (what folks refers to as) platforms.
Core and complete are examples of platforms that the community has defined. They represent different configurations of FOLIO.Core is intended to be a fairly minimal set of modules (however it has grown over time). Complete is a superset of this that contains most (maybe all) of the modules that the project teams support.Most of the FOLIO environments folks use are based upon the complete platform, as are the regular distributions of FOLIO e.g. 2021 R1The reason it’s important in that list is that the FOLIO project teams use different release schedules for things that are in core vs. complete when we are preparing these regular distributions.I hope that helps, please feel free to ask follow up questions if that doesn’t make sense.
I'm wondering if either of you might be able to help me. It has been brought to my attention that mod-aes is part of Platform Complete yet is not present in this list so folks do not know who the responsible party is for it.
Do either of you know which group is responsible for this module?
Based upon the github contributors (Mathew RenoHongwei Ji ), it seems likely that it could be the EBSCO FSE group.
(I'm working on the assumption that we've agreed that all modules in Platform Complete should be in this list here, for support, release management purposes etc)
Oleksiy LemeshkoThere are columns for R2 and R3 new modules. Do we need to update those columns to R2 2021 and R3 2021 to make it clear which releases they are talking about (or maybe use the flower names also)? And do you want to add a new column for R3 2020? I just added a new module to Folijet, but didn't mark anything in any of the "new" columns. Thank you!
Given that mod-inventory now depends upon mod-source-record-manager and mod-data-import-converter-storage. Should these modules now be part of the (mostly defunct, but still used for release planning) core platform?
Marc Johnson We could use this rule to determine core/complete module type -
If a Core module A references module/library B, then the B should be considered as Core as well. It is assumed that A can't work/be assembled properly without B.
Oleksii Petrenko Yes, that is effectively the rule I use (though I think of it as dependencies must be satisfied in order for the platform to be coherent).
I ask this question as a way of suggesting to folks that I think this documentation needs to change without me telling people what to do, as I do not own that information.
SUPPORT: Rather than having a column for each release - could we have a column for "new as of" and "deprecated as of" – expected life cycle ... - as in who is supporting the features/functions...
I think support is asking for how long the feature and function is actively supported - and to consolidate the release columns - we do not want the sheet to wide.....
Instead of multiple columns for different releases and a single value, make it a single-column pivot table with multiple values. i.e. instead of cols for 2021-R2 and 2021-R3 and 2022-R1 and ... all with the single value 'Y', have a single column "Introduced in" with multiple values like 'Juniper', 'Iris', 'Honeysuckle, 'Folio OG'.
18 Comments
Charlotte Whitt
Definition of core vs. complete:
explained in as Slack thread following distinction/definition:
FOLIO systems (the set of modules included) can be defined as (what folks refers to as) platforms.
Core and complete are examples of platforms that the community has defined. They represent different configurations of FOLIO.Core is intended to be a fairly minimal set of modules (however it has grown over time). Complete is a superset of this that contains most (maybe all) of the modules that the project teams support.Most of the FOLIO environments folks use are based upon the complete platform, as are the regular distributions of FOLIO e.g. 2021 R1The reason it’s important in that list is that the FOLIO project teams use different release schedules for things that are in core vs. complete when we are preparing these regular distributions.I hope that helps, please feel free to ask follow up questions if that doesn’t make sense.
Marc Johnson
Oleksii Petrenko Khalilah Gambrell
I'm wondering if either of you might be able to help me. It has been brought to my attention that
mod-aesis part of Platform Complete yet is not present in this list so folks do not know who the responsible party is for it.Do either of you know which group is responsible for this module?
Based upon the github contributors (Mathew Reno Hongwei Ji ), it seems likely that it could be the EBSCO FSE group.
(I'm working on the assumption that we've agreed that all modules in Platform Complete should be in this list here, for support, release management purposes etc)
Oleksii Petrenko
Marc Johnson Thank you so much that you flag this. Hanna Hulevich Could you please assist with
mod-aesmodule?Marc Johnson
Craig McNally Edge-common isn't on this list at the moment. Do you know which team owns it?
Is it the Core Platform team? I'm suggesting that as Adam Dickmeiss did the last release of the library.
Does edge-common-spring (which is also not in this list) have a different owner?
cc: Oleksii Petrenko
Marc Johnson
Oleksii Petrenko Hanna Hulevich
Has it been identified which teams are responsible for mod-aes and edge-common ?
Ann-Marie Breaux
Oleksiy LemeshkoThere are columns for R2 and R3 new modules. Do we need to update those columns to R2 2021 and R3 2021 to make it clear which releases they are talking about (or maybe use the flower names also)? And do you want to add a new column for R3 2020? I just added a new module to Folijet, but didn't mark anything in any of the "new" columns. Thank you!
Victoria Smelova
Updated the Column names and added Lotus as well
Marc Johnson
Magda Zacharska Mikhail FokanovZak_Burke John Malconian
Given that ui-inventory is soon going to depend upon mod-search should mod-search move to platform core rather than complete?
Magda Zacharska
I agree Marc Johnson
Marc Johnson
Ann-Marie Breaux Kateryna Senchenko Oleksii Petrenko
Given that mod-inventory now depends upon mod-source-record-manager and mod-data-import-converter-storage. Should these modules now be part of the (mostly defunct, but still used for release planning) core platform?
cc: Wayne Schneider
Oleksii Petrenko
Marc Johnson We could use this rule to determine core/complete module type -
If a Core module A references module/library B, then the B should be considered as Core as well. It is assumed that A can't work/be assembled properly without B.
Marc Johnson
Oleksii Petrenko Yes, that is effectively the rule I use (though I think of it as dependencies must be satisfied in order for the platform to be coherent).
I ask this question as a way of suggesting to folks that I think this documentation needs to change without me telling people what to do, as I do not own that information.
Julian Ladisch
"If a Core module A references module/library B" should be clarified to
"If a Core module A references module/library B as required (not optional) dependency"
Anya Arnold
SUPPORT: Rather than having a column for each release - could we have a column for "new as of" and "deprecated as of" – expected life cycle ... - as in who is supporting the features/functions...
Oleksii Petrenko
Anya Arnold column with release name mean that marked module will be first time represented at particular release
We do not collect here deprecated modules
Anya Arnold
I think support is asking for how long the feature and function is actively supported - and to consolidate the release columns - we do not want the sheet to wide.....
Oleksii Petrenko
I will think how to figure out your request
Zak_Burke
Instead of multiple columns for different releases and a single value, make it a single-column pivot table with multiple values. i.e. instead of cols for 2021-R2 and 2021-R3 and 2022-R1 and ... all with the single value 'Y', have a single column "Introduced in" with multiple values like 'Juniper', 'Iris', 'Honeysuckle, 'Folio OG'.