Estabilidad y versiones
Esta página dice qué promete el paquete a partir de 1.0.0 y cómo puede cambiar esa promesa. Si algún día se mueve, el registro de cambios dirá dónde.
En corto: lo que está documentado es público, lo demás es detalle de implementación; un nombre solo se retira en una versión mayor; y detrás de cada publicación hay una pasada completa de la puerta de calidad.
Qué es público
Lo que aparece en el contrato de API y en esta web, y nada más. La referencia renderiza esa superficie entera, generada desde las fuentes.
| Superficie | Público | No público |
|---|---|---|
| CSS | Clases iv-* documentadas y sus modificadores; las propiedades locales --iv-<bloque>-* listadas como locales públicos; los atributos de estado data-iv-* documentados | Orden interno de las reglas, pseudoelementos, nombres de @keyframes, valores concretos de sombras y transiciones |
| Tokens | Todos los --iv-* que emite tokens.css: el nombre y su semántica | Lo que no aparece en tokens.json. Un valor puede afinarse en una versión menor mientras el significado se mantenga |
| JavaScript | Los exports del paquete (., ./auto, ./theme, ./<componente>, ./iife, ./css/*, ./tokens.json); clases, métodos, getters, opciones y valores por defecto; los eventos iv:* y su detail; la precedencia defaults < data-iv-* < opciones JS | Miembros que empiezan por _, rutas profundas dentro de dist/, orden de los listeners, temporizaciones exactas |
| HTML servido | La estructura que espera cada componente y su comportamiento sin nada de JavaScript | El marcado que genera init: puede cambiar de forma mientras conserve la semántica documentada |
Versionado
SemVer estricto desde 1.0.0.
| Publicación | Puede contener |
|---|---|
| Mayor | Retirar o renombrar cualquier cosa pública, cambiar un valor por defecto, cambiar el detail de un evento, subir el mínimo de navegadores |
| Menor | Añadir clases, tokens, opciones, métodos, eventos o módulos; afinar valores de tokens sin cambiar su semántica; ampliar el soporte de navegadores |
| Parche | Correcciones que no cambian la superficie pública. Una corrección de accesibilidad puede cambiar marcado generado y sigue siendo parche |
Leído al revés: si tu página solo usa clases documentadas, atributos documentados y los módulos exportados, una subida menor es un cambio de número y nada más.
Deprecaciones
Nada público desaparece sin aviso. Una deprecación se anuncia en el registro de cambios y en esta web una versión menor antes de retirarse en la siguiente mayor, y mientras vive el código avisa una vez por página:
[iVOLT] deprecated: <qué> — usa <reemplazo> (se retira en 2.0)El aviso es un solo console.warn, nunca un error lanzado ni un cambio visible en la página. Al escribir esto no hay ninguna deprecación pendiente.
Etiquetas de npm
| Etiqueta | A qué apunta | Instalación |
|---|---|---|
latest | La versión estable vigente | npm install @intervolutions/ivolt |
next | Candidatas a publicación | npm install @intervolutions/ivolt@next |
beta | Betas del ciclo en curso | npm install @intervolutions/ivolt@beta |
npm install @intervolutions/ivolt te da la versión estable vigente. Fija una versión exacta en producción.
Navegadores
El mínimo es Chromium 113, Firefox 113 y Safari 16.4, con sus versiones móviles, y cada publicación se prueba en Chromium, Firefox y WebKit. Subir ese mínimo es un cambio mayor.
Varias funciones son mejora progresiva y así están declaradas: el atributo popover, text-wrap: balance, animation-timeline (en Firefox el mismo movimiento llega por la reserva de movimiento por scroll), position-anchor, backdrop-filter y field-sizing. Ninguna función pública depende de ellas; un motor antiguo obtiene un resultado más sobrio, no uno roto.
Lo que no se promete
- Igualdad al píxel entre versiones. Las líneas base visuales son de la suite de pruebas del proyecto; no son un contrato contigo.
- Los nombres de archivo dentro de
dist/. Solo son estables las rutas listadas enexports. Una importación profunda puede romperse en un parche. - Las fixtures del paquete como API. Son material de prueba y de documentación.
- El comportamiento con lector de pantalla más allá de lo verificado. La revisión de accesibilidad registra qué se probó y declara con claridad qué no se ejecutó.
Cómo se comprueba
Cada publicación pasa por un solo comando, y una salida distinta de cero es una publicación que no ocurre:
npm run verifyConstruye el paquete, corre las unitarias y las de contrato, lanza la suite de navegador en los tres motores, mide los paquetes contra su presupuesto, empaqueta el tarball y lo instala en un consumidor desechable, y después construye esta web y los ejemplos. Encima de eso, una prueba de contrato regenera la referencia y falla si una clase, opción, evento o token público no está documentado en ningún sitio: por eso la referencia y las páginas no pueden separarse.
Lo que una pasada no pudo verificar se escribe en vez de taparse: esa lista vive junto al estado del proyecto, al lado de los resultados.