TAG MEETING 2024-1-18
Agenda
Release cadence
Future of ODS/API
AMT
Materials
Participants
Notes
These note complement the slide deck above and make the most 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 the meeting: 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.
Analytics Middle Tier
No additional comments.
Bonus Item: Tech Congress
April 22- 24
Indianapolis, IN
Registration will be live soon, end of Jan / early Feb.
Next Meeting: Mar 14, 2024
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?