{"id":766,"date":"2019-07-19T14:58:40","date_gmt":"2019-07-19T20:58:40","guid":{"rendered":"https:\/\/ugit.siua.ac.cr\/?page_id=766"},"modified":"2019-07-19T15:00:41","modified_gmt":"2019-07-19T21:00:41","slug":"versionamiento-semantico-ugit-api-vs-1-0-0","status":"publish","type":"page","link":"https:\/\/sada.services\/?page_id=766","title":{"rendered":"Versionamiento Sem\u00e1ntico: UGIT.API.VS-1.0.0"},"content":{"rendered":"\n

Descargue la \u00faltima versi\u00f3n aqu\u00ed: UGIT.API.VS-1.0.0<\/a><\/p>\n\n\n\n

Terminolog\u00eda usa en este documento<\/strong><\/h2>\n\n\n\n
  • TICs:<\/strong> Tecnolog\u00edas\nde Informaci\u00f3n y Comunicaci\u00f3n<\/li>
  • SIUA:<\/strong> Sede\nInteruniversitaria de Alajuela<\/li>
  • UGIT:<\/strong> Unidad de\nGesti\u00f3n e Innovaci\u00f3n Tecnolog\u00eda<\/li>
  • UGIT.API.VS :<\/strong> UGIT.API\nVersionamiento Sem\u00e1ntico<\/li>
  • TI:<\/strong> Tecnolog\u00edas\nde Informaci\u00f3n<\/li>
  • CONARE:<\/strong> Consejo\nNacional de Rectores<\/li><\/ul>\n\n\n\n

    Objetivo:<\/strong><\/h2>\n\n\n\n

    Establecer un marco de control de sobre el versionamiento sem\u00e1ntico de aplicaciones desarrolladas o implementadas por el personal de la Unidad de Gesti\u00f3n e Innovaci\u00f3n Tecnol\u00f3gica (UGIT) o personal externo dentro de la Sede Interuniversitaria de Alajuela.<\/p>\n\n\n\n

    Alcance<\/strong><\/h2>\n\n\n\n

    Este documento es aplicable y de conocimiento de todo el personal de la Unidad de Gesti\u00f3n e Innovaci\u00f3n Tecnolog\u00eda (de ahora en adelante mencionadas en este documento como UGIT) de la Sede Interuniversitaria de Alajuela (de ahora en adelante mencionadas en este documento como SIUA) y todo el personal interno y externo que desarrolle o implemente una aplicaci\u00f3n tecnol\u00f3gica dentro de la SIUA.<\/p>\n\n\n\n

    Responsabilidades<\/strong><\/h2>\n\n\n\n

    El cumplimiento de este documento es de car\u00e1cter obligatorio para todo el personal de la UGIT, as\u00ed como para usuarios internos y externos que desarrollen o implementen una aplicaci\u00f3n tecnol\u00f3gica dentro de la SIUA y que sea mantenida por el personal de la UGIT.<\/p>\n\n\n\n

    Principios Generales<\/strong>: Presentaci\u00f3n<\/h2>\n\n\n\n

    La presente API p\u00fablica de Versionamiento Sem\u00e1ntico (de ahora en adelante conocida como UGIT.API.VS) son un conjunto de especificaciones de versionamiento sem\u00e1ntico que establecen el est\u00e1ndar oficial para el versionamiento de sistemas desarrollados o implementados en la SIUA y que el departamento de la UGIT ser\u00e1 la encargada de darle soporte a dicha aplicaci\u00f3n.<\/p>\n\n\n\n

    Estructura y Contenido<\/strong><\/h2>\n\n\n\n

    El\npresente documento est\u00e1 organizado siguiendo la siguiente estructura:<\/p>\n\n\n\n

    1. Cap\u00edtulo I: Introducci\u00f3n<\/li>
    2. Cap\u00edtulo II: Especificaci\u00f3n de Versionamiento Sem\u00e1ntico UGIT-SIUA<\/li><\/ol>\n\n\n\n

      Cap\u00edtulo I: Introducci\u00f3n<\/strong><\/h2>\n\n\n\n

      \u00bfPor qu\u00e9 utilizar\nVersionamiento Sem\u00e1ntico?<\/strong><\/strong><\/h3>\n\n\n\n

      Cuando decides utilizar un c\u00f3digo que no es tuyo como puede ser una framework o una librer\u00eda, una de las cosas que debes tomar en cuenta es utilizar la \u00faltima versi\u00f3n de mismo, no solo porque est\u00e1 puede incluir nuevas funcionalidades que te puedan interesar, sino tambi\u00e9n porque puede que esta \u00faltima versi\u00f3n en la cual, acabas de desarrollar todo tu c\u00f3digo no sea compatible con versiones anteriores, por tanto, aqu\u00ed nacen dos problemas del mundo del software. Uno, para el consumidor de ese framework o librer\u00eda es importante conocer si esta \u00faltima versi\u00f3n modifica totalmente el comportamiento y funcionamiento del mismo o solo arregla peque\u00f1os errores u agrega nuevas funcionalidades. Y dos, para el creador del framework o librer\u00eda necesita de una manera de comunicar a sus usuarios la naturaleza y alcance de la \u00faltima versi\u00f3n de su c\u00f3digo. Por esta raz\u00f3n nace lo que hoy d\u00eda se conoce como \u00abVersionamiento Sem\u00e1ntico (Semantic Versioning)\u00bb.<\/p>\n\n\n\n

      Tipo de versiones<\/strong><\/h3>\n\n\n\n

      El\nversionamiento sem\u00e1ntico es un convenio o est\u00e1ndar a la hora de definir la\nversi\u00f3n de tu c\u00f3digo, dependiendo de la naturaleza del cambio o cambios que\nest\u00e1s introduciendo. De tal forma, se identifican 3 tipos de cambios:<\/p>\n\n\n\n

      • Mayor:<\/strong> Cambio\ndr\u00e1stico en el c\u00f3digo. No es compatible con el c\u00f3digo de versiones anteriores.<\/li>
      • Menor:<\/strong> Cambio que\na\u00f1ade alguna o algunas caracter\u00edsticas nuevas al c\u00f3digo o modifica alguna o\nvarias ya existentes, pero que sigue siendo compatible con c\u00f3digo existente.\nTambi\u00e9n cuando marcamos algo como obsoleto que no modifique el funcionamiento\nprincipal.<\/li>
      • Revisi\u00f3n:<\/strong> Cuando\narreglamos un error siendo el cambio compatible con la versi\u00f3n actual o un\naspecto de dise\u00f1o.<\/li><\/ul>\n\n\n\n

        De esta forma, tenemos un lenguaje com\u00fan entre desarrolladores y consumidores a la hora de hablar de versiones.<\/p>\n\n\n\n

        \u00bfC\u00f3mo se marca una versi\u00f3n como mayor, menor o revisi\u00f3n?<\/strong><\/h3>\n\n\n\n

        Cada vez que\nenviemos c\u00f3digo al repositorio crearemos un nuevo \u201ctag\u201d<\/strong> siguiendo el convenio sem\u00e1ntico, dependiendo de los cambios\nintroducidos. El tag contendr\u00e1 la informaci\u00f3n, separando las versiones de cada\ntipo por puntos, de la forma: \u201cmayor.menor.revision\n<\/strong>y este no puede ser cambiado jam\u00e1s, para que si alguien depende de esa\nversi\u00f3n en particular, pueda seguir haci\u00e9ndolo sin problemas.<\/p>\n\n\n\n

        Si el framework o librer\u00eda utiliza el versionamiento sem\u00e1ntico de forma correcta, cualquier usuario que lo utilice puede actualizar sin peligro a todas las versiones marcadas como revisi\u00f3n<\/strong> o menor<\/strong> porque no romper\u00e1n su c\u00f3digo. Por tanto, podr\u00eda actualizar de la versi\u00f3n 5.3.3 a la 5.3.4 o incluso 5.4.0, porque solo estar\u00edan incrementando las versiones menor<\/strong> y revisi\u00f3n<\/strong>, que son compatibles con c\u00f3digo existente.<\/p>\n\n\n\n

        Si por el contrario pasa de la versi\u00f3n 1.4 a la versi\u00f3n 2.0, tendr\u00eda que tener cuidado porque seguramente habr\u00eda muchas cosas que dejar\u00edan de funcionar ya que se ha cambiado la mayor<\/strong>. <\/p>\n\n\n\n

        Identificadores de estabilidad<\/strong><\/h3>\n\n\n\n

        Adem\u00e1s de\npoder definir los cambios en tu c\u00f3digo como mayor<\/strong>, menor<\/strong> o revisi\u00f3n<\/strong>, existen adem\u00e1s unos\nidentificadores que ayudan a marcar versiones especificas que quieras\ndiferenciar, ya que se utilizan para indicar la \u201cestabilidad\u201d de esa versi\u00f3n.<\/p>\n\n\n\n

        Por ejemplo,\nsi tenemos la versi\u00f3n 1.4.6 de una aplicaci\u00f3n y decides comenzar el desarrollo\nde la versi\u00f3n 2.0.0 (incluye cambios no compatibles con las versiones\nanteriores), pero apenas estas comenzando, por tanto; debes indicarles a tus\nusuarios la estabilidad de tu aplicaci\u00f3n para que sepan que todav\u00eda estas en la\netapa de desarrollo para esto se utilizan estos identificadores:<\/p>\n\n\n\n

        • alpha:<\/strong> se encuentra en etapa de desarrollo no es estable. Ejemplo: 2.0.0-alpha<\/li>
        • beta:<\/strong> se encuentra como una posible candidata a ser liberada. Ejemplo: 2.0.0-beta<\/li>
        • rc (Release Candidate):<\/strong> candidata a liberaci\u00f3n el cual lleva un n\u00famero de versi\u00f3n, mientras es liberada. Ejemplo 2.0.0-rc2 (versi\u00f3n 2).<\/li><\/ul>\n\n\n\n

          Opciones adicionales<\/strong><\/h3>\n\n\n\n

          Adem\u00e1s, en de todo lo que se ha mencionado en el desarrollo de software de grandes aplicaciones como video juegos y sistemas operativos es importante considerar el en versionamiento, los parches o fechas de lanzamientos, dependiendo del caso. Para estos podemos agregar un n\u00famero m\u00e1s el versionamiento, por ejemplo:<\/p>\n\n\n\n

          Versi\u00f3n de parche:<\/h4>\n\n\n\n

          Si considera importante el manejo y control de los parches puede agregar un n\u00famero adicional a la estructura pasando de X.Y.Z a X.Y.Z.P donde \u201cP\u201d ser\u00eda el n\u00famero de parche, adem\u00e1s puede utilizar una letra \u201cp\u201d para indicar que es un parche. Por ejemplo: 1.2.5.2 \/ 02.03.03.01 \/ 1.25.4.p2<\/p>\n\n\n\n

          Versi\u00f3n por fecha<\/h4>\n\n\n\n

          Si considera importante el manejo y control de las fechas de liberaci\u00f3n de su aplicaci\u00f3n podemos adicionar la fecha al versionamiento. En este caso el formato y el orden puede variar dependiendo de las necesidades, por ejemplo puede querer utilizar los cuatro d\u00edgitos del a\u00f1o (2019, 2010, \u2026) o solo dos d\u00edgitos (19, 10, \u2026), puede querer utilizar el a\u00f1o de primero, luego el mes y d\u00eda \u00f3 d\u00eda, mes y a\u00f1o, pero todo va depender de sus necesidades, como adicional el desarrollo de un software siempre requiere bastante tiempo invertido por lo que si es necesario utilizar las fecha dentro del versionamiento le recomendamos utilizar el a\u00f1o de primero.<\/p>\n\n\n\n

          Cap\u00edtulo II: Especificaci\u00f3n de Versionamiento Sem\u00e1ntico UGIT-SIUA<\/strong><\/h2>\n\n\n\n
          • Cualquier software desarrollado o implementado dentro de la SIUA, por el personal de la UGIT, personal interno o externo a la SIUA debe se\u00f1alar el uso de este documento como est\u00e1ndar oficial de versionamiento a trav\u00e9s de los mecanismos:
            • Enlace p\u00fablico \/?page_id=756 <\/li>
            • O plasmarlo directamente dentro del c\u00f3digo <\/li><\/ul><\/li><\/ul>\n\n\n\n
              • El versionamiento de una versi\u00f3n de software ser\u00e1 identificada por\ntres d\u00edgitos enteros no negativos, siguiendo el patr\u00f3n X.Y.Z, donde:<\/li><\/ul>\n\n\n\n
                \n Clave\n <\/td>\n Nombre\n <\/td>\n \u00bfCu\u00e1ndo?\n <\/td>\n Ejemplos\n <\/td><\/tr>
                \n X\n <\/td>\n Mayor:<\/strong> representa un cambio\n grande en el software.\n <\/td> La versi\u00f3n mayor X (X.y.z y X > 0) DEBE ser incrementada si cualquier cambio no compatible con la versi\u00f3n anterior es introducido a la aplicaci\u00f3n. PUEDE incluir cambios de nivel menor y\/o revisi\u00f3n. Las versiones revisi\u00f3n y menor DEBEN ser reseteadas a 0 cuando se incrementa la versi\u00f3n mayor. <\/td>\n i.<\/strong> Se eliminan\n funcionalidades.\n ii.<\/strong> Se modifica el\n funcionamiento de funciones que hacen incompatibles con las versiones\n anteriores.\n iii.<\/strong> Se marca como obsoleto\n funcionalidades principales.\n <\/td><\/tr>
                \n Y\n <\/td>\n Menor:<\/strong> representa un cambio menor\n compatible con versiones anteriores\n <\/td> La versi\u00f3n menor Y (x.Y.z y x > 0) DEBE ser incrementada si se introduce una nueva funcionalidad compatible con la versi\u00f3n anterior. Se DEBE incrementar si cualquier funcionalidad de la aplicaci\u00f3n es marcada como obsoleta. PUEDE ser incrementada si se agrega funcionalidad o arreglos considerables al c\u00f3digo. Puede incluir cambios de nivel revisi\u00f3n. La versi\u00f3n revisi\u00f3n DEBE ser reseteada a 0 cuando la versi\u00f3n menor es incrementada. <\/td>\n i. <\/strong>Se agregan nuevas\n funcionalidades con compatibilidad a la versi\u00f3n actual\n ii.<\/strong> Se marca como obsoleto\n funciones que no afectan a la aplicaci\u00f3n principal.\n <\/td><\/tr>
                \n Z\n <\/td>\n Revisi\u00f3n:<\/strong> representa un cambio de\n aspecto o correcci\u00f3n de un error peque\u00f1o.\n <\/td> La versi\u00f3n revisi\u00f3n Z (x.y.Z y x > 0) DEBE incrementarse cuando se introducen solo arreglos compatibles con la versi\u00f3n anterior. Un arreglo de error se define como un cambio interno que corrige un comportamiento err\u00f3neo. \u00a0 <\/td>\n i. <\/strong>Se corrigen fallas que no\n afectan el funcionamiento principal.\n ii. <\/strong>Modificaci\u00f3n de aspectos\n est\u00e9ticos.\n Se\n corrigen fallas que no afectan el funcionamiento principal.\n ii.<\/strong> Modificaci\u00f3n de aspectos\n est\u00e9ticos.\n <\/td><\/tr><\/tbody><\/table>\n\n\n\n
                • Cada elemento del versionamiento se debe incrementar num\u00e9ricamente en incrementos de uno (1).<\/li>
                • Una vez que un paquete versionado ha sido liberado (release), los contenidos de esa versi\u00f3n NO DEBEN ser modificadas. Cualquier modificaci\u00f3n DEBE ser liberada como una nueva versi\u00f3n.<\/li>
                • La versi\u00f3n mayor en cero (0.Y.Z) es para desarrollo inicial por lo que no debiera ser considerada estable.<\/li>
                • La versi\u00f3n 1.0.0 define la primera versi\u00f3n estable de la aplicaci\u00f3n.<\/li>
                • La versi\u00f3n revisi\u00f3n Z (x.y.Z y x > 0) DEBE incrementarse cuando se introducen solo arreglos compatibles con la versi\u00f3n anterior. Un arreglo de error se define como un cambio interno que corrige un comportamiento err\u00f3neo.<\/li>
                • La versi\u00f3n menor Y (x.Y.z y x > 0) DEBE ser incrementada si se introduce una nueva funcionalidad compatible con la versi\u00f3n anterior. Se DEBE incrementar si cualquier funcionalidad de la aplicaci\u00f3n es marcada como obsoleta. PUEDE ser incrementada si se agrega funcionalidad o arreglos considerables al c\u00f3digo. Puede incluir cambios de nivel revisi\u00f3n. La versi\u00f3n revisi\u00f3n DEBE ser reseteada a 0 cuando la versi\u00f3n menor es incrementada.<\/li>
                • La versi\u00f3n mayor X (X.y.z y X > 0) DEBE ser incrementada si cualquier cambio no compatible con la versi\u00f3n anterior es introducido a la aplicaci\u00f3n. PUEDE incluir cambios de nivel menor y\/o revisi\u00f3n. Las versiones revisi\u00f3n y menor DEBEN ser reseteadas a 0 cuando se incrementa la versi\u00f3n mayor.<\/li>
                • Se establecen la utilizaci\u00f3n de los siguientes identificadores de estabilidad, lo cuales ser\u00e1n escritos en letras min\u00fasculas y separados del versionamiento por un guion medio (\u201c-\u201d):<\/li><\/ul>\n\n\n\n
                  \n Nombre\n <\/td>\n Estado de estabilidad\n <\/td>\n Ejemplo\n <\/td><\/tr>
                  \n alpha<\/strong>\n <\/td>\n La aplicaci\u00f3n se encuentra\n en el desarrollo, todav\u00eda no es una versi\u00f3n estable.\n <\/td>\n 2.0.0-alpha\n <\/td><\/tr>
                  \n beta<\/strong>\n <\/td>\n La aplicaci\u00f3n se encuentra\n en un desarrollo final para ser probada para solicitar ser candidata a\n liberaci\u00f3n.\n <\/td>\n 2.1.3-beta\n <\/td><\/tr>
                  \n rc<\/strong>\n <\/td>\n La aplicaci\u00f3n esta lista\n para ser liberada como una versi\u00f3n candidata, para pasar a pruebas de\n usuario. Adem\u00e1s, es necesario que se establezca un n\u00famero de versi\u00f3n para\n este tipo, donde es un n\u00famero entero incremental en uno (1), por ejemplo:\n rc01, rc02, \u2026, rc10, rcN, si el n\u00famero es menor 10 (N<10), se debe agregar\n un cero (\u201c0\u201d) delante del n\u00famero. Ejemplo: rc01, rc02, \u2026, rc09.\n <\/td>\n 2.4.5-rc01\n 2.4.5-rc02\n <\/td><\/tr><\/tbody><\/table>\n","protected":false},"excerpt":{"rendered":"

                  Descargue la \u00faltima versi\u00f3n aqu\u00ed: UGIT.API.VS-1.0.0 Terminolog\u00eda usa en este documento TICs: Tecnolog\u00edas de Informaci\u00f3n y Comunicaci\u00f3n SIUA: Sede Interuniversitaria de Alajuela UGIT: Unidad de Gesti\u00f3n e Innovaci\u00f3n Tecnolog\u00eda UGIT.API.VS : UGIT.API Versionamiento Sem\u00e1ntico TI: Tecnolog\u00edas de Informaci\u00f3n CONARE: Consejo Nacional de Rectores Objetivo: Establecer un marco de control de sobre el versionamiento sem\u00e1ntico de […]<\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-766","page","type-page","status-publish","hentry"],"blocksy_meta":{"styles_descriptor":{"styles":{"desktop":"","tablet":"","mobile":""},"google_fonts":[],"version":6}},"_links":{"self":[{"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/pages\/766","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sada.services\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=766"}],"version-history":[{"count":4,"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/pages\/766\/revisions"}],"predecessor-version":[{"id":771,"href":"https:\/\/sada.services\/index.php?rest_route=\/wp\/v2\/pages\/766\/revisions\/771"}],"wp:attachment":[{"href":"https:\/\/sada.services\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=766"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}