Control de versiones

En esta guía, se explica cómo la API de Merchant controla el control de versiones, los lanzamientos y el ciclo de vida de sus diferentes versiones.

Esquema del control de versiones

La API de Merchant emplea una estrategia de control de versiones a nivel de sub-API. Esto significa que cada API de Merchant, por ejemplo, Productos dentro de la API de Merchant, tendrá su propio ciclo de vida de la versión.

Formato y presentación del control de versiones

• Versiones estables de la sub-API: Si una sub-API está en una versión estable, todos sus métodos también lo están. Una versión estable de la sub-API se representa como vX (por ejemplo, v1, v2). Estas son versiones principales listas para la producción.

• Versiones alfa de la sub-API: Si una sub-API está en una versión alfa, todos sus métodos también lo están. Una versión alfa de la sub-API se representa como vXalpha (por ejemplo, v1alpha, v2alpha). Contienen funciones experimentales de acceso anticipado diseñadas para pruebas y una iteración rápida. Las versiones alfa no tienen garantía de estabilidad, no tienen una vida útil definida y se pueden cambiar o descontinuar con un período de aviso de 30 días.

Cambios en la versión

• Incrementos de la versión principal (por ejemplo, de v1 a v2): Indican cambios rotundos e incompatibles con versiones anteriores, que requieren la acción del desarrollador. Solo los cambios rotundos de las sub-APIs estables tendrán un número de versión nuevo. Por ejemplo, de v1 a v2.
• Cambios menores: Las adiciones o correcciones compatibles con versiones anteriores se presentan como cambios en la versión principal existente. Estos cambios se detallarán en las notas de la versión de esa versión principal. Las adiciones no rotundas a una sub-API se lanzarán al canal alfa de la versión estable más reciente o directamente a la versión estable más reciente.

Política de baja

Periódicamente, damos de baja las versiones más antiguas de las sub-APIs de Merchant. Nos comprometemos a un período de baja de 12 meses para las versiones principales estables (vX), a partir del anuncio oficial de baja.

Por ejemplo, si damos de baja la versión v1 de la sub-API de Productos el 15 de enero de 2026, no se dará de baja antes del 15 de enero de 2027. Después de esta fecha, la versión anterior de la sub-API ya no estará disponible para su uso.

Versión de la sub-API y estado del ciclo de vida

En la siguiente tabla, se enumeran las versiones más recientes de cada sub-API de la API de Merchant:

Prácticas recomendadas

• Consulta periódicamente las notas de la versión y las actualizaciones más recientes para obtener información sobre las versiones nuevas, las actualizaciones principales, las mejoras y los anuncios sobre los lanzamientos y las bajas de las sub-APIs.
• Si una sub-API tiene dos o más versiones estables, te sugerimos que uses la versión más reciente en todo momento.
• Diseña tu aplicación para que controle correctamente varios errores de la sub-API, incluidos los problemas de red, los límites de frecuencia y los nuevos códigos o mensajes de error que se pueden introducir con versiones más recientes de la sub-API.
• No esperes hasta que una versión de la sub-API esté a punto de darse de baja para comenzar a planificar la actualización. Comienza a evaluar y probar las versiones nuevas en cuanto estén disponibles.
• Si tienes solicitudes de funciones o inquietudes sobre una hoja de ruta de la sub-API, comunícate con nosotros para hacernos preguntas o comentarios. Para obtener información sobre cómo comunicarte con el equipo de la API de Merchant para obtener asistencia técnica, consulta Obtén ayuda con la API de Merchant.