¡Buenas noticias! Al añadir una dependencia desde GitHub, ahora tiene acceso a una nueva regla: Follow 4D version. Esta poderosa adición asegura que sus dependencias se mantengan sincronizadas con su entorno 4D sin esfuerzo, reduciendo los problemas de compatibilidad y haciendo que su flujo de trabajo sea más fluido que nunca.

SIMPLIFIQUE LA GESTIÓN DE DEPENDENCIAS

Con la regla Follow 4D version, ya no tendrá que controlar manualmente qué versiones de dependencias se alinean con su versión 4D. El gestor de dependencias se encarga de ello por usted, asegurando que las versiones más relevantes y compatibles se seleccionen automáticamente. Esto significa:

• Menos trabajo manual: no necesita buscar las versiones correctas usted mismo.
• Menos problemas de compatibilidad: sus dependencias siempre coinciden con su entorno 4D.
• Más estabilidad: mantenga su proyecto funcionando sin problemas, incluso al actualizar o degradar de 4D.

ACTUALIZACIONES SIN ESFUERZO Y COMPATIBILIDAD FIABLE

Cuando actualice su versión de 4D, sus dependencias seguirán siendo válidas y podrá obtener fácilmente las últimas versiones compatibles. Si baja de versión, el sistema ajustará automáticamente sus dependencias para que coincidan con su nueva versión.

ETIQUETADO DE VERSIONES PARA SU RESOLUCIÓN AUTOMÁTICA

Para que este sistema funcione con eficacia, los colaboradores deben asegurarse de que las dependencias sigan una convención estructurada de nomenclatura de etiquetas. El gestor de dependencias resolverá las dependencias basándose en estas reglas de versionado:

Versiones LTS: las etiquetas deben seguir el patrón x.y.p, donde:

• x representa la versión mayor de 4D.
• y representa la versión menor.
• p permite flexibilidad para versiones correctivas o actualizaciones adicionales.

Ejemplo: 20.2.3 (mayor: 20, menor: 2, correctiva: 3) o 21.6.1 (mayor: 21, menor: 6, correctiva: 1).

Cuando su proyecto especifica que sigue una versión 4D LTS (por ejemplo, 20.2), el Gestor de Componentes siempre intentará resolver a la última versión de esa serie 20.* si está disponible. Si no se encuentra la versión exacta que está buscando, automáticamente volverá a una versión anterior de esa serie, como 20.1.p o 20.0.p, si están disponibles.

Versiones R: las etiquetas deben seguir el modelo `xRy.p`, donde:

• xR corresponde a la versión mayor.
• y representa la versión menor.
• p permite incluir parches y actualizaciones incrementales.

Ejemplo: 20R3.2 (Mayor: 20R, Menor: 3, Parche: 2) o 21R5.1 (Mayor: 21R, Menor: 5, Parche: 1).

Cuando su proyecto especifica una versión de R como 20R3, el Gestor de Componentes intentará primero resolver a la última versión de la serie 20R3.p. Si esa versión no está disponible, buscará una versión de la serie 20R* inferior o igual a 20R3, como 20R2.p o 20R1.p.

Los componentes 4DPop y 4DPop-Macros ya respetan las convenciones de etiquetado estructurado y garantizarán una resolución de dependencias sin problemas con la regla de versión Follow 4D.

Tenga en cuenta que, si tiene sus propios componentes con reglas de nomenclatura personalizadas, puede mantener su número de versión en el título de sus lanzamientos. Sin embargo, la etiqueta debe seguir estrictamente el formato requerido.

CÉNTRESE EN SU CÓDIGO, NO EN SUS DEPENDENCIAS

Con Follow 4D version, la gestión de dependencias nunca ha sido tan sencilla. Ya sea que esté actualizando, degradando o manteniendo su proyecto, puede confiar en que sus dependencias siempre se alinearán con su entorno 4D.

Pruébelo ahora y experimente una forma más inteligente y sin complicaciones de gestionar las dependencias.