I reckon this (and that it can be used in conjunction with grants) implies they're translating the old config to the new format if it exists on the fly. Otherwise, if it involved running two things one in maintenance mode (and somehow ensuring they both take effect and don't conflict) it'd be ballsy to promise 'forever'.
Although not sure why that's preferable to converting it once-off, so it's still not something a user has to worry about, but then the old way is done with.
Stripe has been doing it for god knows how long now and it seems to be working for them. With a robust test suite, I can’t think of too much that can/would go wrong. Honestly, I wish more software would approach things this way instead of introducing a major api version every 5 years. Just continuously ship the latest thing and translate everything that came before. Hopefully if people are also using “official” client libraries, they will eventually upgrade their dependencies and their API version will also get bumped. If there is a particularly heavy usage client jumping forward 100 versions and using too many of your resources, hopefully your org can dedicate some resources to help them upgrade which theoretically benefits both of you.
Now that I think of it Adyen did this to us a few years back. We’ll probably stay in the v5 branch until they politely poke us to upgrade again in another 5 years…
> Although not sure why that's preferable to converting it once-off, so it's still not something a user has to worry about, but then the old way is done with.
This way also supports users who have scripts or workflows that produce the old form of ACLs. If you had a single cut-off date, those scripts would presumably need to be updated.
We are indeed converting the old syntax to grants behind the scenes. In fact, we have been quietly doing this for months :)
As tczMUFlmoNk mentioned further down, we wanted to allow both syntaxes in perpetuity to account for scripts, Terraform configs, version-controlled policy files, and other automation that may rely on the original syntax.
We will provide a button on the JSON editor in our admin console to do a one-click conversion for anyone who would like to make a hard switch.
They probably have a parser that parses to some other format. They only need to maintain the parser and they probably won't support new features on it.
Although not sure why that's preferable to converting it once-off, so it's still not something a user has to worry about, but then the old way is done with.