|
Top-level
 @dansup i respectfully dont agree with you. As a de facto central dev authority they can just 1-code properly to avoid breakage of 3rd party apps because of the new features , and 2-just publish an update notice and everyone will follow. I want to avoid false reasons based on potential technical incompetence. 5 comments
@dansup i am not familiar with the code base, true, and devil is usually in the details I know, but I am familiar with long term compatibility of evolving products. A stable versioned api is good. I think most of the work should be on client apps, right? Client apps can test for new versions of APIs and gracefully fall back on previous versions? This sounds like a valid design pattern even if I'm not actually familiar with the implementation details...  @f4grx No yeah, I understand, and in a perfect world, clients would be able to negotiate that but in reality it's a lot more complicated than that. For example, clients have to parse the software to know what APIs they are dealing with, and such a complex feature like Comment Controls would need to be implemented carefully so as to not break existing APIs, while gracefully handling clients that can Now throw in forks like glitch, it's not so easy to determine the API schema and thus, this feat @dansup yeah, devil in the details as usual. If that compatibility rule is not baked it from inception it's hard to do later. I work with smart carts, with long develop/deploy cycles, so we usually think about the future much more than in a web app. Yet this "careful" design is possible everywhere. It's probably also more annoying to design. I understand. |
Gregory's Server
@f4grx it's not that simple, they don't differentiate between official and 3rd party apps
The whole point of a versioned API is to be stable, so they would need to update certain endpoints while not breaking bc
Seems like you're not that familiar with the codebase, so i wouldn't be so quick to give suggestions