Sistema de versiones y repositorio de diseño de derivaciones

With the release for beta we’ve moved SpongeAPI versioning to semantic versioning (see https://semver.org/). This change means that every time that we make a release we have to increment the version according to the rules of 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.

The layout of our branches (described below) is designed to assist this process by allowing us to make minor releases without a breaking change forcing us to make it a major release. This branch layout applies to SpongeAPI, SpongeCommon, SpongeForge, and SpongeVanilla repositories but not to the SpongeDocs.

SpongeAPI, SpongeCommon, SpongeForge y SpongeVanilla

La Rama Sangrante

The core of our repositories is the bleeding branch. Almost all changes will be added to bleeding, including new features, changes, and bugfixes. The version of bleeding will always be the next major release version appended with -SNAPSHOT (e.g. 6.0.0-SNAPSHOT) to denote that it is not yet a final build and subject to change.

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

The SpongeDocs themselves are unversioned following our philosophy that they will never be finished, but instead in a constant flux of ever increasing usability. However, they target a specific version of the API, generally the most recent release of 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.

A feature branch may only be merged into master if the changes / additions made in it are correct regarding the SpongeAPI release currently targeted by the SpongeDocs. Any feature branches that describe features not yet included in a release stay unmerged until the corresponding API version is released and becomes the new targeted version for the SpongeDocs. However, the Docs team might collect additions for a specific version on a single branch.

release branch example

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.