Convenciones para campo de estabilidad de los paquetes de Cabal

Cabal permite una forma libre Stability field:Convenciones para campo de estabilidad de los paquetes de Cabal

estabilidad: de forma libre

El nivel de estabilidad del paquete, por ejemplo, alpha, experimental, provisional, stable.

¿Cuáles son las convenciones de la comunidad sobre estos valores de estabilidad? ¿Qué se considera experimental y qué es provisional? Veo que solo algunos paquetes están declarados como stable. ¿A qué tipo de estabilidad se refiere, a la estabilidad de la API expuesta o al último estado libre de errores del software?

Fuente

2010-10-01 sastanin

Personalmente, creo que esto es profundamente objetivo. Simplemente explore las librerías estándar y vea cuántas de ellas son "provisionales" o "experimentales". – fuz

Eso es exactamente lo que me molesta.Si incluso las bibliotecas centrales son en su mayoría solo provisionales y experimentales, entonces ¿qué nosotros, los simples mortales, podemos reclamar sobre nuestro código? No me gusta llamarlo todo igualmente provisional, pero me gustaría ver cómo la gente entiende esto. – sastanin

El campo está casi desaparecido ahora, y no se debe utilizar. Como dijo Max, probablemente sea reemplazado por algo significativo en el futuro.

Si está interesado en la historia, el campo se originó en una propuesta de diseño para el primer conjunto de Hierarchical Haskell Libraries. Ese documento describe los significados originales previstos para los valores.

Fuente

2010-10-02 20:54:05

Gracias, Simon. Creo que la pregunta está respondida ahora. – sastanin

El enlace está muerto por ahora. –

Actualmente este campo es una guía muy pobre para la estabilidad de la biblioteca, por lo que se ignora en su mayoría. Duncan Coutts (uno de los principales desarrolladores de Cabal y Hackage) ha dicho que finalmente planea reemplazar este campo por completo, con algo así como un sistema de votación social en Hackage.

Personalmente (y no estoy solo) siempre omito el campo de estabilidad. Dado que se va a ir, probablemente no vale la pena perder el sueño sobre qué poner en él.

Fuente

2010-10-02 14:42:59

Sí. O sustitúyalo por un sistema para optar por una política de control de versiones, p. Norma de control de versiones estándar. http://www.haskell.org/haskellwiki/Package_versioning_policy –

Los significados pretendidos originales eran:

experimental: el API es inestable. Puede cambiar en cualquier momento, es decir, cualquier cambio de número de versión;
provisional: la API es hacia la estabilidad. Se puede cambiar en cada revisión menor, pero debe proporcionar versiones obsoletas de las características;
estable: la API es estable. Solo se deben hacer adiciones en versiones menores. Después de los cambios en la API, las características en desuso deben mantenerse para al menos una versión principal.

Como las otras respuestas señalaron, la comunidad parece no para ser siguiente estas pautas más.

Como Simon Marlow señala, esto se describe en una propuesta de diseño para el primer conjunto de bibliotecas jerárquicas Haskell. El enlace original está muerto, pero puede encontrar una copia en el wayback machine.

Fuente

2014-09-10 10:57:29

Convenciones para campo de estabilidad de los paquetes de Cabal

Respuesta

Cuestiones relacionadas