Sistema de versiones y repositorio de diseño de derivaciones
Con el lanzamiento de la beta hemos movido la versión de SpongeAPI a versión semántica (véase https://semver.org/). Este cambio significa que cada vez que hacemos un lanzamiento tenemos que incrementar la versión según las reglas de semver.
SemVer
SemVer utiliza el esquema de “” X.Y.Z””, donde “”X”” es una versión importante, “”Y”” es una * menor * y “” Z”” finalmente es una versión parche. Un lanzamiento que contiene cambios que no son compatible debe ser una versión mayor por delante de la lanzada anteriormente. Si hay características nuevas que son todavía compatibles con versiones anteriores, entonces la nueva versión será una versión menor por delante de la lanzada anteriormnete, y si la versión estrictamente contiene correcciones de errores entonces sólo la versión parche se incrementa.
Esto significa que por ejemplo “”3.2.0”” es totalmente compatible con “”3.0.0”” mientras que “”4.0.0”” no es binariamente compatible con “”3.0.0””. “”3.1.0”” y “”3.1.2”” son completamente intercambiables además de los errores que se arreglaron.
El diseño de nuestras ramificaciones (descritas abajo) está diseñado para asistir con este proceso al permitirnos hacer lanzamientos menores sin tener un cambio importante que nos oblige a hacer un lanzamiento mayor. Este diseño aplica a los repositorios SpongeAPI, SpongeCommon, SpongeForge y SpongeVanilla, pero no al de Spongedocs.
SpongeAPI, SpongeCommon, SpongeForge y SpongeVanilla
La Rama Sangrante
El núcleo de nuestros repositorios es la rama bleeding``(sangrante). Casi todos los cambios serán añadidos a ``bleeding, incluyendo funciones nuevas, cambios y soluciones a errores. La versión de bleeding siempre será la versión más grande que saldrá concatenada con -SNAPSHOT``(ej ``6.0.0-SNAPSHOT) para denotar que aún no es la última versión y está sujeta a cambios.
La razón principal por la cual tener un ramal “sangrante” es para contar con un ámbito de prueba para los cambios. Incluso los miembros más experimentados del equipo Sponge pueden accidentalmente causar una falla en la creación o pasar por alto un error. El ramal “sangrante” será testeado por miembros de la comunidad que buscan lo más nuevo, y eso significa que podremos solucionar las fallas con más celeridad y facilidad.
Ramas Estables
Derivaciones estables, representan una plataforma mucho más estable en donde se puede construir complementos e implementaciones de servidores. No habrá fracturas para con el API, solo adiciones que no rompan nada. Hay una derivación para cada lanzamiento mayor del API, el cual contiene la ultima implementación/API para dicho lanzamiento incluyendo cualquier lanzamiento que sea menor o que sea un parche.
Cuando llegue el momento de lanzar una versión grande, una nueva rama stable-x será creada desde bleeding, donde x es la versión más grande - por ejemplo, stable-5. bleeding será apropiadamente actualizada para ser la próxima versión grande, como se describió anteriormente.
Los cambios que han estado en este ramal “sangrante” por un tiempo, que no tengan fallas visibles y que puedan ser aplicados a un lanzamiento previo de magnitud, serán escogidos cuidadosamente para ser parte del ramal “estable” para un lanzamiento futuro. Los cambios serán agrupados en una versión menor, a menos que se prefiera corregir una falla inmediatamente, caso en el cual se creará una versión mejorada. Cada vez que se lanza una versión, el banco de datos de API creará una etiqueta para identificar las características de ese lanzamiento.
Características de sucursales
Nuevas características o cambios deben crearse en la derivacion “”feature/foo”” o “”fix/bar””. Esto debe basarse en la confirmación más reciente a “”bleeding””. La única excepción a esto es si los cambios son incompatibles con los cambios de última hora en “”bleeding”, en cuyo caso debe basarse contra la pertinente “”stable-x””. Usted debe indicar en su solicitud de extracción por qué el cambio no puede ser incluido en la “” bleeding””, como por ejemplo corregir un error en una función que fue quitada por Mojang en una versión posterior.
Si los cambios realizados no están necesitando de una versión anterior, el equipo Sponge puede también escoger los cambios en una o más derivaciones “”stable”” asumiendo que no hay problemas después de que el cambio es combinado en “”bleeding””.
SpongeDocs
Los mismos SpongeDocs no tienen versiones al seguir nuestra filosofía de que nunca serán terminados, sino que se encuentran en un flujo constante de usabilidad cada vez mayor. Sin embargo, ellos apuntan a una versión específica del API, generalmente la versión más reciente de SpongeAPI.
Rama Central
La derivación base para SpongeDocs es “”stable””. Cada nueva encomienda a “”stable”” desencadena una reconstrucción de la página web de documentos < https://docs.spongepowered.org/>” _. Las encomiendas a “”stable”” se hacen generalmente para documentar el lanzamiento más actual de SpongeAPI o para corregir errores menores en los documentos.
Características de sucursales
Siempre que se describa una nueva característica, Los textos más viejos son actualizados o redactados o los documentos son reestructurados, esto se realiza en una “”feature/foo”” o una derivación “”fix/bar””. Estas derivaciones luego se examinarán y, una vez que se consideren completas, se pueden combinar.
Un ramal accesorio podrá ser incorporado al máster si los cambios/adiciones que posee son correctas con respecto a ** El lanzamiento de SpongeAPI que en ese momento avala SpongeDocs**. Cualquier ramal accesorio que describa características que todavía no hayan sido incluídas en un lanzamiento, no serán incorporados hasta que la versión correspondiente de API no sea lanzada y se convierta en la versión avalada por SpongeDocs. De todas maneras, el equipo de Docs puede recolectar adiciones para una versión específica en un solo ramal.
Sucursales de lanzamiento
SpongeDocs usa las derivaciones release/x.y.z``para publicar documentos de versiones de API viejas como el API ``3.1.0. Los lanzamientos de API más viejos están disponibles en sus respectivas derivaciones. Siempre que una nueva versión de API es lanzada, el personal de los documentos crearán una nueva derivación release/x.y.z``para luego empezar con la nueva versión de API. Una encomienda para una derivación ``release también ocasiona una reconstrucción de los documentos lanzados anteriormente, tal cual como sucede en la derivación principal.
