A resposta de Doc Brown está mais próxima da precisão, as outras respostas ilustram os mal-entendidos do Princípio do Aberto Fechado.
Para articular explicitamente o mal-entendido, parece haver uma crença de que o OCP significa que você não deve fazer alterações incompatíveis com versões anteriores (ou mesmo quaisquer alterações ou algo assim.) O OCP é sobre projetar componentes para que você não precise fazer alterações neles para estender sua funcionalidade, independentemente de essas alterações serem compatíveis com versões anteriores ou não. Há muitas outras razões além de adicionar funcionalidade que você pode fazer alterações em um componente, sejam elas compatíveis com versões anteriores (por exemplo, refatoração ou otimização) ou incompatíveis com versões anteriores (por exemplo, descontinuando e removendo funcionalidades). O fato de você poder fazer essas alterações não significa que seu componente violou o OCP (e definitivamente não significa que você esteja violando o OCP).
Realmente, não é sobre código-fonte. Uma declaração mais abstrata e relevante do OCP é: "um componente deve permitir a extensão sem necessidade de violar seus limites de abstração". Eu iria mais longe e diria que uma versão mais moderna é: "um componente deve reforçar seus limites de abstração, mas permitir extensão". Mesmo no artigo sobre OCP de Bob Martin enquanto ele "descreve" "fechado à modificação" como "o código-fonte é inviolável", ele mais tarde começa a falar sobre encapsulamento que não tem nada a ver com modificação de código fonte e tudo a ver com abstração limites.
Assim, a premissa falha na questão é que o OCP é (pretendido como) uma diretriz sobre as evoluções de uma base de código. O OCP é tipicamente sloganizado como "um componente deve estar aberto a extensões e fechado a modificações pelos consumidores". Basicamente, se um consumidor de um componente quiser adicionar funcionalidade ao componente, ele deve ser capaz de estender o componente antigo para um novo com a funcionalidade adicional, mas eles devem Não é possível alterar o componente antigo.
O OCP não diz nada sobre a funcionalidade criador de um componente alterando ou removendo . O OCP não está defendendo a manutenção da compatibilidade de bugs para todo o sempre. Você, como criador, não está violando o OCP alterando ou até mesmo removendo um componente. Você, ou melhor, os componentes que você escreveu, estão violando o OCP, se a única maneira pela qual os consumidores podem adicionar funcionalidade a seus componentes é por meio da alteração, por exemplo. por monkey patching ou ter acesso ao código-fonte e recompilação. Em muitos casos, nenhuma delas é uma opção para o consumidor, o que significa que, se o seu componente não estiver "aberto para extensão", estará sem sorte. Eles simplesmente não podem usar seu componente para suas necessidades. O OCP alega não colocar os consumidores de sua biblioteca nessa posição, pelo menos no que diz respeito a alguma classe identificável de "extensões". Mesmo quando modificações podem serem feitas no código-fonte ou até mesmo na cópia primária do código-fonte, é melhor "fingir" que você não pode modificá-lo, pois há muitas conseqüências negativas em fazê-lo .
Então, para responder às suas perguntas: Não, essas não são violações do OCP. Nenhuma alteração feita por um autor pode ser uma violação do OCP porque o OCP não é uma proporção de alterações. As alterações, no entanto, podem criar violações do OCP, e podem ser motivadas por falhas do OCP em versões anteriores da base de código. O OCP é uma propriedade de uma parte específica do código, não da história evolutiva de uma base de código.
Por contraste, a compatibilidade retroativa é uma propriedade de uma alteração do código. Não faz sentido dizer que alguma parte do código é ou não compatível com versões anteriores. Faz sentido apenas falar sobre a compatibilidade retroativa de algum código em relação a algum código antigo. Portanto, nunca faz sentido falar sobre o primeiro corte de algum código sendo compatível com versões anteriores ou não. O primeiro corte de código pode satisfazer ou não satisfazer o OCP e, em geral, podemos determinar se algum código satisfaz o OCP sem referir-se a nenhuma versão histórica do código.
Quanto à sua última pergunta, é indiscutivelmente fora do tópico para o StackExchange em geral como sendo basicamente baseado em opinião, mas o que falta é bem-vindo à tecnologia e particularmente JavaScript onde nos últimos anos o fenômeno que você descreve tem sido chamado fadiga JavaScript . (Sinta-se à vontade para google encontrar uma variedade de outros artigos, alguns satíricos, falando sobre isso de múltiplas perspectivas.)