Underscore: O sublinhado não segue SemVer

Para citar https://github.com/jashkenas/backbone/issues/2888#issuecomment -29076249:

Obrigado, mas seguir estritamente o versionamento "semântico" não funcionaria muito bem para o Backbone. Dado que o projeto é quase toda área de superfície e muito pouco interno, quase qualquer alteração (patch, pull request) no Backbone quebra a compatibilidade com versões anteriores de alguma forma ... mesmo que apenas para as pessoas que dependem de um comportamento anteriormente indefinido.

O resto do comentário vale a pena ler também, mesmo que você discorde.

https://github.com/jashkenas/coffeescript/issues/3352#issuecomment -34217211 também

@akre54 Estou curioso para saber o que você pensa sobre o fato de que outros projetos como Lo-Dash (alternativa Underscore) e ExosJS (alternativa Backbone) podem seguir semver?

Uma vez que essas substituições _podem seguir semver_, isso não atrapalha a desculpa empurrada pelo núcleo Underscore/Backbone?

Coisas de casal.

Lo-Dash, na maioria das vezes, adere às trilhas pavimentadas por Underscore, por isso tem a vantagem de adiar até um lançamento de Underscore para empurrar um aumento de versão para paridade de recursos. As diferenças do Underscore tendem a ser mais na categoria de aprimoramentos e menos em mudanças significativas.

O Lo-Dash adiciona muito mais código de guarda para bc às custas da desordem de código, enquanto o Underscore se esforça para ser conciso. É mais fácil se safar com algumas linhas de código extra quando a biblioteca é maior para começar (Lo-Dash atinge 8,7k linhas versus 1,4k para Underscore). Há também muito mais mucking interno que pode ser feito em Lo- Dash, já que grande parte da lógica é interna.

Também é escrito desproporcionalmente por um colaborador (você), enquanto as alterações do Underscore tendem a vir de um conjunto muito mais diversificado de colaboradores, o que significa que novos recursos podem surgir a qualquer momento e, às vezes, grandes alterações de recursos e alterações incompatíveis com versões anteriores vêm em momentos inoportunos para um cronograma de lançamento.

Curiosamente, tenho a sensação de que Underscore também tem a desvantagem de cronograma de lançamento de ser usado em muito mais projetos iniciantes do que Lo-Dash (por sua própria natureza, Lo-Dash tende a atrair desenvolvedores que precisam de seu poder). Um desenvolvedor mais avançado ficará mais confortável lidando com as consequências de mudanças de última hora e pode entender um pouco mais o raciocínio deles.

Por fim, como co-autor e principal colaborador de Exoskeleton, serei o primeiro a dizer que também não estamos acompanhando o tempo todo. Também temos as vantagens do Lo-Dash, conforme descrito acima.

Lo-Dash, na maioria das vezes, adere às trilhas pavimentadas por Underscore, por isso tem a vantagem de adiar até um lançamento de Underscore para empurrar um aumento de versão para paridade de recursos. As diferenças do Underscore tendem a ser mais na categoria de aprimoramentos e menos em mudanças significativas.

O que isso tem a ver com a estratégia de versão do Underscore? Lo-Dash bate as versões após o semver e é por isso que está na v2.x indo para a v3.x.

O Lo-Dash adiciona muito mais código de guarda para bc às custas da desordem de código, enquanto o Underscore se esforça para ser conciso.

O que o código de guarda ou ser conciso tem a ver com a estratégia de versão?

É mais fácil escapar com algumas linhas de código extra quando a biblioteca é maior para começar (Lo-Dash atinge 8,7k linhas versus 1,4k para Underscore).

Lo-Dash tem documentos embutidos, LOC não é relevante para versionamento.

Há também muito mais mucking interno que pode ser feito no Lo-Dash, já que grande parte da lógica é interna.

O mesmo não pode ser dito para o Underscore?

Também é escrito desproporcionalmente por um colaborador (você), enquanto as alterações do Underscore tendem a vir de um conjunto muito mais diversificado de colaboradores, o que significa que novos recursos podem surgir a qualquer momento e, às vezes, grandes alterações de recursos e alterações incompatíveis com versões anteriores vêm em momentos inoportunos para um cronograma de lançamento.

É por isso que o Underscore tem mantenedores para aceitar/rejeitar ou adiar até uma versão futura.
Novamente, não é relevante para versionamento.

Curiosamente, tenho a sensação de que Underscore também tem a desvantagem de ser usado em muito mais projetos iniciantes do que Lo-Dash (por sua própria natureza, Lo-Dash tende a atrair desenvolvedores que precisam de seu poder).

Discordo, Lo-Dash tem milhares de dependentes e nem todos podem ser especialistas nisso.

Um desenvolvedor mais avançado ficará mais confortável lidando com as consequências de mudanças de última hora e pode entender um pouco mais o raciocínio deles.

Como o Lo-Dash segue os desenvolvedores semver, não precisa lidar com as consequências até que eles saltem para uma atualização de versão principal. Ao contrário do Underscore, o Lo-Dash não muda porque eles usaram um ~ para o intervalo de versões do pacote.

Por fim, como co-autor e principal colaborador de Exoskeleton, serei o primeiro a dizer que também não estamos acompanhando o tempo todo.

Então você deve remover isso de seu marketing.

Eu não acho que haja alguma razão para que o Underscore não possa seguir semver.
Não segui-lo é um desserviço aos seus usuários :frowning:

Se você quer ser incluído no npm ou no bower, não está em debate. Você deve usar semver. Você está fazendo uma promessa implícita de seguir sempre, e se não o fizer, isso quebra o código das pessoas sem aviso, e isso é desaprovado por praticamente todo mundo.

Estamos falando de uma escolha que quebra o código de produção. Não é legal jogar um jogo desleixado com o tempo e dinheiro de outras pessoas.

Isso significa que seus números de versão aumentam mais rapidamente. E daí? É um número. Isso é muito melhor do que quebrar o carrinho de compras de produção de alguém.

+1 para sempre

Pessoalmente, não acho "legal" obter _personal_ em um relatório de bug. Ou ele faz ou não segue o versionamento semântico. Aqui estão as razões - bang, bang, bang - porque seria uma biblioteca ainda melhor se tivesse. Aqui estão as razões - bang, bang - porque é viável para os mantenedores incrementar o número da versão de uma maneira congruente com semver.

Depois disso, cabe aos mantenedores. Se você discordar da posição deles, existem bibliotecas alternativas para usar. Você pode fazer um fork do projeto (como outros fizeram). Você pode escrever uma postagem no blog ficando tão pessoal quanto quiser.

Mas vamos tentar ter um desacordo civil.

Eu não entendo @raganwald. Quem está ficando pessoal?

Não estou atacando ninguém. Estou apontando que semver faz parte do contrato de API que você entra quando publica um pacote no npm ou no bower.

Se você quebrar esse contrato, você quebra o código de outras pessoas. Isso não é legal.

O npm funciona muito bem porque todos concordamos com algumas regras que mantêm nossos módulos funcionando bem uns com os outros. Se você quebrar essas regras, você quebra outros módulos que tentam trabalhar com o seu. Você quebra aplicativos de produção que dependem do seu código.

A questão não é "devemos usar semver?" A questão é: "queremos ser bons cidadãos neste ecossistema?"

O ponto-chave é que em um projeto como o Underscore, _toda_ mudança está afetando alguém. Se removermos um null guard de _.extend (para usar um exemplo aleatório) porque está causando um bug para alguém e cria um bug para outra pessoa, isso é um patch? Essa é uma versão menor? Principal?

Para Underscore e Backbone, não acho que seja razoável fixar suas dependências. Seguir semver não é um requisito para publicar em um empacotador.

O ponto-chave é que em um projeto como o Underscore, cada mudança está afetando alguém.

Você está pulando ao extremo para justificar sua posição. A realidade é que é um equilíbrio. Há API popular, casos extremos e comportamento documentado. É muito possível passar um tempo sem atualizar uma versão principal simplesmente corrigindo bugs e adicionando funcionalidades.

O que isso significa é que os mantenedores precisam pensar e planejar. Isso significa que você pode ter que criar um roteiro para recursos ou alterações que não podem ser resolvidos sem quebrar a compatibilidade e tudo bem.

Underscore aumentou os lançamentos de patches e introduziu grandes mudanças. Isso é algo que os mantenedores podem controlar totalmente.

Para Underscore e Backbone, não acho que seja razoável fixar suas dependências.

Deve haver uma mensagem/aviso na documentação com certeza.

@akre54 Alterar recursos _não documentados_ ou _bugs não documentados_ pode quebrar o código que depende deles, mas os usuários confiam em recursos e bugs não documentados por sua conta e risco.

Ignorar semver coloca _todo usuário_ de sua API em perigo. As pessoas corrigem bugs em grandes projetos de código aberto que seguem semver o tempo todo, mas _é realmente raro ver grandes números de versão no ecossistema npm_.

Por que é que?

Porque _todas as boas APIs seguem o princípio aberto/fechado_ (aberto para extensão, fechado para alterações importantes) o mais próximo possível, para que os usuários possam acompanhar o ritmo da API e as alterações não interrompam o código existente.

Para adicionar às anedotas, meu código também foi quebrado por solavancos de sublinhado no passado. Recorremos a cometer node_modules para evitá-lo porque --save --save-exact não é suficiente. Se uma dependência de segundo nível depende do Underscore e usa uma versão ^x.y.z , seu aplicativo ainda está quebrado.

Quanto aos números de versão indicando progresso, não me importo. Usar a versão 2.1.3 ou 143.3.2 não faz diferença para mim. O progresso e a maturidade da biblioteca não são medidos em números de versão. Eu só não quero um telefonema no domingo à tarde porque alguém atualizou uma dependência que depende de underscore@^x.y.z .

:thumbsup: Sim. @braddunbar faz um ponto que eu ainda não consegui - ignorar semver torna seu pacote um pacote perigoso e virulento, porque essa mudança de ruptura pode estar demorando _em qualquer lugar_.

É _definitivamente um requisito oneroso_ forçar os usuários a caçar falhas no código de terceiros que dependem do seu pacote quebrado.

IMO, o progresso e a maturidade reais da biblioteca são medidos em confiabilidade e sempre percorrem um longo caminho para atingir esse objetivo.

Deve haver uma mensagem na documentação com certeza.

Com certeza. Fico feliz em adicionar um, se for o que decidirmos.

Eu não sou contra um sistema de lançamento melhor (Deus sabe que é difícil esperar meses para que sua pequena correção de bug seja implantada), mas não tenho certeza se "seguir semver" é a resposta certa.

Agora, eu não acho que importa se é a única resposta certa. É _é_ a resposta aceita pela comunidade.

Eu não acho que alguém disse que "seguir semver" é a resposta certa para um sistema de lançamento melhor. O que dissemos é que é o contrato da API npm e que quebrar esse contrato causa danos.

@jdalton e @dilvie Como você propõe que tratemos dos lançamentos? E quanto a aceitar recursos? "Use semver" realmente não nos diz nada.

Devemos adiar recursos como _.matches por alguns meses para que possamos esperar correções de bugs para o código atual, ou devemos liberá-lo agora e deixar as pessoas resolverem os problemas de implementação?

Eu acho que semver simplesmente não se aplica totalmente aqui.

Autopromoção sem vergonha: use next-update https://github.com/bahmutov/next-update para testar primeiro se as dependências podem ser atualizadas sem quebrar seu projeto. Constantemente encontrei alterações em diferentes módulos, apesar da alteração de *.*.x , então agora não confio em nenhuma versão autodeclarada.

Você acha que este projeto é um floco de neve? Lo-Dash é basicamente Underscore++, e seguir semver não é problema para @jdalton.

Aceitando novos recursos:

Isso quebra o contrato de API existente?

Sim? - aumentar o número da versão principal.
Não? - aumentar o número da versão menor.

Aceitando correções de bugs / patches menores:

Ele quebra o contrato de API existente?

Sim? - aumentar o número da versão principal.
Não? - número da versão do patch de colisão.

A forma como você escolhe agendar lançamentos oficiais depende inteiramente de você. Apenas certifique-se de que o versionamento seja sempre compatível para que você não quebre o código de outras pessoas.

Concordou com @dilvie , por exemplo https://github.com/jashkenas/underscore/compare/1.3.3...1.4.0 provavelmente deveria ter sido um grande obstáculo, pois abandonamos o suporte para matrizes esparsas. A próxima versão deve ser um grande salto, pois adicionaremos uma tonelada de novo açúcar via lookupIterator e eliminaremos os iteradores nativos.

Se a documentação de uma função tiver que mudar, é claramente uma grande mudança

Eu entrei em uma breve discussão sobre isso no JSconf este ano. Não tenho tempo para entrar em detalhes aqui, mas:

pare de confundir "versão de versão" voltada para humanos com "compatibilidade de API" voltada para o computador (ou, na verdade, voltada para o sistema de compilação). simplesmente pare.

Versão: “Essa coisa que eu gosto tem novos recursos, ou outra coisa que eu deveria me interessar quando tiver tempo.” Há um novo iPhone. Há um novo OS X. Há um novo Ember. Há um novo relatório revisado sobre o esquema de linguagem algorítmica.

Compatibilidade da API: “Esta coisa foi atualizada para corrigirproblema, e isso pode/vai quebrar o caminhoexercita essa coisa.” O plugue de alimentação do iPhone foi substituído. As bifurcações de recursos obsoletas do OS X. O Ember preteriu um estilo de nomes de ação. Scheme agora faz distinção entre maiúsculas e minúsculas.

O último acontece _durante_, ou _ao lado_ do primeiro; mas o primeiro não é necessariamente dependente ou mesmo relacionado ao último. Eles devem ser rastreados e (se realmente vamos _especificar_ um sistema de versão, jesus) especificados separadamente. (o conceito de 'versão semântica' popular na comunidade JS é _particularmente_ obtuso e terrível; mas, novamente, não é algo que eu queira entrar em detalhes no tópico de comentários de outra pessoa.)

tl;dr: Eles não estão estragando seu ecossistema escolhendo seu próprio caminho. (_Especialmente_ quando esse caminho é terrivelmente falho.) Eu gostaria que mais projetos fossem. Vá usar outra coisa, se você estiver tão fora de forma por causa disso.

@elliottcable - concordado sobre a face humana versus a face do computador ... Desde que a face humana não se pareça em nada com a face do computador, para que a fusão seja menos problemática.

Talvez chame o próximo lançamento voltado para humanos de algo como "floco de neve" em vez de nnn

Discordo totalmente com a última parte, no entanto. Quando você finge seguir um contrato de API e depois o quebra, as coisas quebram. Custa a outras pessoas tempo real e dinheiro real. Com um projeto tão popular quanto o sublinhado, há potencialmente muitos danos reais.

Isso quebra o contrato de API existente?

Olhe para trás para os primeiros argumentos neste segmento. "Tudo no Underscore é basicamente área de superfície", ergo, tudo, documentado e não, faz parte de seu contrato de API. Qualquer mudança é uma mudança para todos.

Lo-Dash, sendo "Underscore++" não lida com tantas mudanças nos recursos porque pode seguir com segurança atrás do Underscore na elaboração dos principais recursos. As melhorias do Lo-Dash estão principalmente sob o capô ou na adição de alguns métodos, não repensando fundamentalmente seus recursos.

@akre54

Como você proporia que tratássemos de lançamentos? E quanto a aceitar recursos? "Use semver" realmente não nos diz nada.

Você pode aceitar uma nova API ou até mesmo algumas melhorias na API existente. Se você adicionar uma nova API ou aprimoramentos (que não quebram a compatibilidade), é uma atualização de versão secundária.

Devemos adiar recursos como _.matches por alguns meses para que possamos esperar correções de bugs para o código atual, ou devemos liberá-lo agora e deixar as pessoas resolverem os problemas de implementação?

Acho que _.matches é bem simples. Sempre haverá correções de bugs.

Eu acho que semver simplesmente não se aplica totalmente aqui.

Claro que sim. Você está começando a se preocupar com o ciclo de lançamento, que é separado do semver, mas vou segui-lo até lá.

@dilvie : vai ficar de fora do resto do argumento, mas jogando isso: realmente, realmente gosto da sua sugestão de seguir a convenção 'nome da versão'. (=

Para a parte voltada para humanos, sou um grande fã de versões de estilo less :

> less --version
less 418
Copyright (C) 1984-2007 Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Homepage: http://www.greenwoodsoftware.com/less

… junte isso com um nome bonito, para deixar bem claro que estamos falando de versão “interessante”, não compatibilidade com API, e você tem um combo vencedor.

+1 para sublinhado 42: "Silly Sheltie".

(Quanto à parte voltada para o sistema de compilação, tenho algumas opiniões controversas sobre compatibilidade de API automatizada e generativa. Vamos tirar essa merda das mãos de mantenedores falíveis, por favor, e atacá-la com análise estática ou rastreamento dinâmico.)

@akre54

Lo-Dash, sendo "Underscore++" não lida com tantas mudanças nos recursos porque pode seguir com segurança atrás do Underscore na elaboração dos principais recursos.

Afinal, o que isso quer dizer? Lo-Dash lida com _mais mudanças_ e segue seu próprio versionamento separado do Underscore. Lo-Dash mudou tanto que teve que oferecer uma versão compatível com o Underscore para continuar seu suporte de ser um substituto imediato. Temos diferentes recursos , métodos e diferentes preocupações de compatibilidade de API.

As melhorias do Lo-Dash estão principalmente sob o capô ou na adição de alguns métodos, não repensando fundamentalmente seus recursos.

Também não é esse o caso. Lo-Dash se move em um ritmo mais rápido e corre contra a compatibilidade traseira com mais frequência. É por isso que estamos ~v2.x em ~v3.x. Lo-Dash é semelhante ao Underscore. Se Lo-Dash pode seguir semver, o Underscore também pode. Eu fiz isso por ~ 2 anos agora. Seus argumentos simplesmente caem diante da realidade.

Já passei por esse caminho antes, então posso ajudar vocês a chegar lá também.
Para começar, o próximo lançamento do Underscore daria um ótimo 2.0.

Estou curioso para saber como todos pensam que "mudança de ruptura" deve ser definida. _Cada_ nova mudança de recurso para Underscore é uma mudança de última hora para outra pessoa.

Vamos pegar por exemplo todas as mudanças recentes em _.each . Deveríamos ter aumentado quando alteramos o valor de retorno de _.each para retornar a lista original ? Isso é uma correção de bug? Um novo recurso? Uma mudança incompatível com versões anteriores? Ele retornou undefined antes, então é improvável que tenha quebrado o código de alguém.

Deveríamos ter batido quando permitimos que o ajudante interno each fosse reatribuído externamente ? Isso poderia ter quebrado o código de alguém? Nenhuma API pública foi alterada lá.

Alterar _.each para evitar matrizes esparsas e usar loops for em vez de forEach nativo obviamente está quebrando para alguns, mas como matrizes esparsas estão mortas, quem realmente se importa? É algo que devemos empurrar uma versão principal? Isso é uma correção de bug?

Acho que estamos atrasados ​​em um grande aumento de versão (muita coisa aconteceu em 219 commits ). Uma versão 2.0 e uma solidificação de nossa política de versão ajudariam muito aqui.

@akre54

Cada nova mudança de recurso para Underscore é uma mudança de última hora para outra pessoa.

Não necessariamente.

Vamos tomar por exemplo todas as mudanças recentes em _.each. Deveríamos ter batido quando alteramos o valor de retorno de _.each para retornar a lista original? Isso é uma correção de bug?

Não é uma correção de bug, é um aprimoramento. É ininterrupto?-- Provavelmente é uma mudança segura porque é improvável que o valor de retorno de _.each fosse confiável e não algo que os desenvolvedores relataram como sendo um obstáculo ao mudar para o Lo-Dash. Em caso de dúvida, afaste-se da quebra ou teste as águas com uma liberação RC. Se a mudança fosse permitir a saída antecipada de _.each , eu diria que foi uma mudança definitiva, pois os desenvolvedores se deparam com isso ao usar o CoffeeScript.

Deveríamos ter batido quando permitimos que cada ajudante interno fosse reatribuído externamente? Isso poderia ter quebrado o código de alguém? Nenhuma API pública foi alterada lá.

Eu diria que se enquadra em detalhes de implementação não documentados. Na época, a mudança não permitia nada de novo porque o Underscore ainda era ramificado para métodos nativos. Essa mudança se enquadra no grupo maior de mudanças no post 1.6.0, então pode pousar em um 2.0.

Alterar _.each para evitar matrizes esparsas e usar loops for em vez de forEach nativo é obviamente ruim para alguns, mas como matrizes esparsas estão mortas, quem realmente se importa? É algo que devemos empurrar uma versão principal? Isso é uma correção de bug?

Pode ser visto como uma correção de bug, mas é definitivamente uma mudança de ruptura. Essa é uma das coisas que os desenvolvedores encontram quando mudam para o Lo-Dash. Por causa de como o Underscore costumava ser, usando nativo quando disponível, ele mascararia o uso de array esparso e os desenvolvedores só encontrariam o problema se testassem em navegadores mais antigos. No entanto, com essa mudança, os desenvolvedores serão alertados sobre o uso de arrays esparsos mais cedo, em navegadores modernos, então há uma chance de que seu código de trabalho anterior encontre um problema.

Acho que estamos atrasados ​​em um grande aumento de versão (muita coisa aconteceu em 219 commits). Uma versão 2.0 e uma solidificação de nossa política de versão ajudariam muito aqui.

:+1:

mudança de ruptura f (plural mudanças de ruptura)

(computação) Uma mudança em uma parte de um sistema de software que potencialmente faz com que outros componentes falhem; ocorre com mais frequência em bibliotecas compartilhadas de código usado por vários aplicativos
"Não é possível corrigir entradas antigas sem uma alteração importante, portanto, remapeie antigo para novo no import lib."

Parte disso requer algum pensamento e julgamento. Pode ser verdade que todas as mudanças quebram o código de alguém, mas se todos os participantes concordarem em usar o princípio aberto/fechado como um guia para o que constitui quebra, isso torna a vida de todos mais fácil.

Portanto, adicionar qualquer propriedade ou método à API geralmente não é uma alteração importante (a API está aberta para extensão, mas fechada para alterações incompatíveis com versões anteriores).

As alterações nas assinaturas de função exigem mais reflexão.

Deveríamos ter batido quando alteramos o valor de retorno de _.each para retornar a lista original?

Esse foi um recurso documentado da API que serviu a algum propósito? Por exemplo, algumas funções retornam indefinidas quando as entradas passadas não resultariam em uma saída sensível. Esse não parece ser o caso de each ... Então, provavelmente não está quebrando.

Evitar arrays esparsos, por outro lado, tem um potencial maior para alterar os valores de retorno nos quais os desenvolvedores confiam, então, claramente, essa é uma mudança importante, e qualquer um que usou arrays esparsos se importa.

Arrays esparsos podem não sobreviver ao ES6, mas ainda não estão mortos.

@akre54
Às vezes, a resposta para saber se uma mudança está falhando ou não não é direta. Nesses casos, o contexto, o histórico e os dados ajudam. É uma sorte que eu tenha sido capaz de usar o Lo-Dash como um campo de testes para novos recursos e ver quais mudanças atrapalham os desenvolvedores vindos do Underscore. O sublinhado pode, por sua vez, usar isso para ajudar a tomar decisões informadas sobre o impacto das mudanças.

No mínimo, o semver seguinte ajudará a evitar que grandes mudanças importantes entrem em lançamentos de patches e incentivará os desenvolvedores a pensar sobre o impacto de suas alterações. Isso é uma vitória para todos.

@jdalton , ato de classe. :)