3 ms·
I don't see how a design decision made by the maintainers of this project, which is documented as version changes are made - and completely transparent given th
by apimade 3y ago
I don't see how a design decision made by the maintainers of this project, which is documented as version changes are made - and completely transparent given the nature of the project (open-source), constitutes a high priority support request from a software engineer external to the project? Sure, it's a pain for adopters who were dependent on the feature, but you can't criticise design decisions made by someone who offers your software for free. You can, however, fork it and take your own path with the software.
Are you saying because a new version breaks the current build of a downstream proprietary application, that should constitute a high priority support request from the maintainers of the project?
That doesn't compute with me. If they were paying for forwards-compatibility and had that expectation in a contract, sure. But they should be able to make changes they see fit without having to make trade-offs to ensure future compatibility with an Enterprise organisation's product.
At that point they're basically making design decisions to suit the Enterprise, at which case - you're not just free resources for software engineering for the organisation, you're actively pushing your project to be vendor-compatible. I could see this reasoning if your project is largely funded by them (Chromium), but in this case, they're not.