Documentación de cambio de versión JSLEstoy seguro de que todos nos hemos encontrado con clientes con este problema... un cliente está usando JMP 13 y se niega a actualizar a versiones más nuevas por razones de compatibilidad con JSL. Dice que tiene miles de scripts que deberían actualizarse y no le queda claro qué actualizaciones son necesarias. ¿Tenemos alguna documentación/guía que especifique cómo convertir un script JMP 13 a 16+? Una búsqueda superficial no arroja nada.
Re: Documentación de cambio de versión JSLEntonces, después de una búsqueda exhaustiva, lo único que pude encontrar es esto: Nuevas características y notas de la versión de JMP® - Comunidad de usuarios de JMP
Pero esta documentación no cubre todos los cambios de JSL que se han producido (por ejemplo, referencias de nombres de columnas en JMP16), ni ninguna de las mejores prácticas para convertir scripts JSL 13 a 16+.
Parece que hay una brecha en la documentación para convertir JSL antiguo a uno nuevo, y esto está afectando la adopción por parte de los clientes de versiones más nuevas de JMP.
Re: Documentación de cambio de versión JSL¡JMP Development tiene el mismo problema con JMP! Las nuevas versiones del IDE, el compilador o las bibliotecas de códigos y los cambios de los desarrolladores en el código fuente pueden dañar JMP. Adoptamos las mejores prácticas de pruebas unitarias de la industria hace mucho tiempo. Publicamos el marco de prueba unitaria JSL que utilizamos internamente en la comunidad JMP hace mucho tiempo. Realizamos miles de millones (bueno, tal vez no tantas) de pruebas todas las noches después de la compilación diaria para verificar correcciones de errores y nuevas características y que no se hayan introducido regresiones. Esta prueba está completamente automatizada o también podemos ejecutar pruebas individuales.
Las empresas que dependen de scripts JMP también deberían adoptar esta práctica. No evita errores, pero le ayuda a encontrarlos cuando desarrolla o modifica scripts o actualiza a una nueva versión de JMP.
Desarrollar pruebas unitarias requiere más trabajo. Requiere una reflexión y un diseño cuidadosos y más tiempo de desarrollo. Dividimos el esfuerzo de programación y pruebas en JMP Development (otra mejor práctica). Aun así, es posible que las empresas sólo tengan unos pocos programadores JSL, de modo que el mismo desarrollador pueda escribir scripts y pruebas unitarias.
La documentación es esencial. Dedicamos mucho esfuerzo a que sea lo más útil posible. ¿Cómo utilizarías una lista exhaustiva de todos los cambios de JSL en tantas versiones de JMP? Las pruebas unitarias apuntarían a los cambios en el JSL que realmente utiliza. Es mucho más efectivo y práctico.
Re: Documentación de cambio de versión JSL¡Ey! Los cambios en las secuencias de comandos no siempre aparecieron en esas notas de la versión. Una fuente más confiable es el apéndice de notas de compatibilidad de la guía de secuencias de comandos. Eso le indicará la mayoría de los errores entre la versión para la que es la guía y la versión anterior. Tendrías que incrementar para obtener todo.
Dicho esto, he tenido muchos clientes en este barco y generalmente les digo que son un farol. Les recuerdo que pueden tener dos versiones en la misma máquina. Les digo que instalen el nuevo junto con el anterior y que ejecuten sus scripts más críticos o complejos en la nueva versión y vean si funcionan. Si algo se rompe, nos ocuparemos de ello. Pero lo curioso es que nada lo ha hecho nunca. Es posible que el registro muestre algo como "esta característica se eliminará en una versión futura". notas, pero el script aún se ejecuta. Los desarrolladores han hecho un trabajo sólido manteniendo la compatibilidad futura en JSL. He utilizado esta estrategia para scripts escritos desde la versión 7.
El único problema (de cualquier tipo) con el que me he topado es la coincidencia del controlador ODBC con el bitness de JMP. Pero eso no es un problema de JSL. Cuando ese problema ocurre, arroja un error claro en el registro. Pero creo que 13 fue la primera versión de 64 bits únicamente. Entonces eso no debería ser un problema.Re: Documentación de cambio de versión JSLSi los clientes tienen tantos scripts y programas, es una pena que no hayan participado ya como pioneros. Además del control de versiones y las pruebas unitarias, esta es la mejor manera de comprobar si los scripts seguirán ejecutándose en la próxima versión (incluso si la empresa no actualiza, para fines de prueba, una sola máquina con la que probar sería suficiente).
Desde el punto de vista de la compatibilidad, espero varios problemas desde JMP 13 a una versión más nueva tan pronto como utilicen elementos de la plataforma para recopilar valores, esquemas y similares. Como algunas plataformas han cambiado el estilo y la estructura en versiones anteriores, esto seguramente aparecerá.
Sin embargo, comenzaría a guiarlos hacia las mejores prácticas de codificación. Y anímelos a participar en las reuniones del Scripters' Club. En esta página encontrarás todas las sesiones grabadas en los últimos 2,5 años del European Scripters' Club. Con algunas sesiones de orientación y mejores prácticas, pero también con un plan de estudios completo en 2023. Estas sesiones han sido gestionadas y presentadas por usuarios reales de nuestra base de clientes que son responsables de la formación, la automatización y más en sus empresas.
Re: Documentación de cambio de versión JSLAquí hay otro recurso excelente: https://www.jmp.com/en_us/articles/unit-tests.html
