Agenda
- Release cadence
- Future of ODS/API
- AMT
Materials
Participants
Notes
These note complement the slide deck above and only make sense when read along with the deck.
Release and Cadence
- Two-year overlap is very helpful for SIS vendors; slower release of breaking changes is more favorable in general.
- SEA's are challenged with downstream effects of breaking changes, in addition to the impact on clients.
- May have many code changes to apply internally to accept the change.
- Almost impossible to make upgrades in back-to-back years.
- Thus would like to avoid having consecutive year breaking changes, as implied by the current "break-break-rest" strategy.
- Sense of themeeting: the "break-rest-rest revised" model, which includes the two years of overlap between prior and current breaking change, seems to be the best fit for all.
- Reminder: technology has now been separated from Data Standard, making it possible to upgrade a data standard without taking breaking technology changes.
- The slide deck originally showed versions like "4.0", "5.0", and "6.0", leading to a question about minor versions.
- The deck now has "4.x", "5.x", "6.x", etc., to indicate that this is talking about the major version number, which is only incremented when there are breaking changes.
- During the supported lifetime of 5.x, for example, there may be multiple minor releases: 5.1, 5.2, etc.
- Each of those minor releases is fully backward compatible with the minor release before, i.e. 5.2 would be backward compatible with 5.0 and 5.1.
- How does this impact certification?
- Did not previously track minor releases, but going forward, vendors will be able to declare which specific version they're targeting for certification.
- An organization that certifies on 5.0 in 2024 could update to 5.1 in 2025 if desired, by simply showing that they now also support new features provided in Data Standard 5.1.
- New features in Data Standard 5.1 are likely to be domain-specific, meaning that the SIS Vendor or Assessment Vendor certifications would likely not have new requirements.
Future of ODS/API
- 99% backward compatible: wiggle room is due to a case sensitivity issue. For years the Ed-Fi documentation had invalid casing on sample OAuth requests. The casing worked just fine with the ODS/API, but violates the OAuth 2 specification. The OAuth / Open ID provider used in Project Tanager might not handle improperly-cased token requests.
- Will the Data Management Service provided through Project Tanager support streaming data output?
- Yes. And we'll try to have that in the workable beta release by Summit 2024.
- Suite 4:
- Version Matrix page in Tech Docs is very confusing and requires a good deal of explanation for newcomers.
- Project Tanager will move us to an API-first mindset, where we talk much more about the API version (which matches the Data Standard) and much less about the application version.
- Why would we consider calling it "suite 4"? To group together the software that belongs together, i.e. the Data Management Service and the Admin Service.
- Who is the audience for the "suite 4" term?
- Those trying to run the software themselves.
- Ed-Fi needs to modify Tech Docs content to clarify this.
- Sense of the meeting: this is a major set of changes, and calling it "suite 4" might be appropriate. However, it could also add further confusion, so it should only be done with caution.
- Will we be able to use a different query database (i.e. Elasticsearch), as envisioned in Meadowlark?
- The architecture will be there to support that possibility, though we might not code for it right away.
- Plugin architecture would support use of third party libraries.
Bonus Item: Tech Congress
- April 22- 24
- Indianapolis, IN
- Registration will be live soon, end of Jan / early Feb.
Next Meeting:
- Building a Validation Ecosystem
- Should the community do more to share validation processes and knowledge?
- What tools / practices should the Ed-Fi Alliance consider to facilitate such an exchange?