¿Hay un opuesto para el término "Backporting"?


20

Según tengo entendido, el término "Backporting" se usa para describir una solución que se aplica en una versión futura que también se transfiere a una versión anterior. La definición de Wikipedia es la siguiente:

El backporting es la acción de tomar una determinada modificación de software (parche) y aplicarla a una versión anterior del software para la que se creó inicialmente. Forma parte del paso de mantenimiento en un proceso de desarrollo de software ...

Por ejemplo:

  • Se descubre y soluciona un problema en V2.0. La misma solución se transfiere y se aplica a V1.5.

¿Cuál es el término cuando esto se hace en la dirección opuesta?

  • El problema se descubre y soluciona en V1.5. La misma solución se transfiere y se aplica a V2.0.

¿Se seguiría aplicando el término "Backporting"? ¿O hay un término como "Forwardporting" (que suena divertido como "Port Forwarding")?


1
¿Qué pasa con la "propagación"?
Gill Bates

Respuestas:


28

Es lo mismo que lo contrario de una barra invertida. Todos quieren llamarlo una barra diagonal, pero en realidad es solo una "barra". Lo opuesto al backporting es simplemente "portar".


"Portar" es un término más general y puede aplicarse a cualquier transferencia de código, incluso entre idiomas. En mi empresa utilizamos "portado hacia adelante" para el caso específico descrito en esta pregunta.
Marko Topolnik

14

Esto generalmente no sucede, ya que solucionaría dicho problema en la base de código V2.0 y, opcionalmente, lo respaldaría. :) En términos de control de versiones, esto simplemente se llama merging.


3
Esto sucede porque V1.xy V2.x coexisten y se mantienen en paralelo, cada uno en su propia rama de mantenimiento. Se puede descubrir y corregir un error de versión cruzada en cualquier lado.
Marko Topolnik

3
Si ya se lanzó V1.5, pero V2.0 se lanzará en el futuro, primero debe solucionar el problema en V1.5, porque esta versión ya la utilizan los clientes y necesita una solución más urgente. Luego, transfiere la solución a V2.0.
user1364368

@ user1364368 la gestión de versiones es una preocupación ortogonal. tiene más sentido corregir el error en la versión más reciente de la base de código, ya que contiene más información (su historial de cambios es un superconjunto del historial de cambios de la versión anterior). piense de otra manera: no tenga en cuenta que el cambio está relacionado con un error. ¿preferiría introducir cambios en una versión anterior? ¿podría, por ejemplo, iniciar el desarrollo de funciones en una versión anterior de la base de código? esto se reduce muy rápidamente a una estrategia de desarrollo sin sentido, recursiva hacia atrás
awdz9nld

@ MartinKällman El jefe de la base de código (para V2.0) podría estar (debido al trabajo de desarrollo actual) en un estado que no le permite desarrollar la solución. Pueden pasar días o semanas hasta que el jefe de la base de código vuelva a estar limpio, pero no puede esperar tanto tiempo para la corrección de emergencia.
user1364368

1

Supongo que usaría los términos: a prueba de futuro o, alternativamente, compatibilidad hacia adelante :

De Wikipedia a prueba de futuro :

Prueba futura: la frase prueba futura describe el proceso exclusivo de tratar de anticipar desarrollos futuros, de modo que se puedan tomar medidas para minimizar las posibles consecuencias negativas y aprovechar las oportunidades.

Y compatibilidad hacia adelante :

La compatibilidad hacia adelante o hacia arriba (a veces confundida con la extensibilidad) es un concepto de compatibilidad para el diseño de sistemas, como, por ejemplo, la compatibilidad con versiones anteriores. La compatibilidad directa apunta a la capacidad de un diseño para aceptar con gracia las entradas destinadas a versiones posteriores de sí mismo.

O ambos "a prueba de futuro a través de la compatibilidad directa"

Oh la palabra de moda :)


0

Hacer backport en la dirección opuesta es solo portar , pero no hay razón para hacerlo en el contexto que usted describe.


0

Creo que el término "backport" se refiere solo a la acción de llevar una característica de una nueva versión de un programa a una versión anterior del mismo programa, por los beneficios de seguir usándolo.

Como no desarrolla una nueva característica en versiones antiguas y cerradas, no existe una copia de seguridad "inversa" (si, por definición, la versión no es antigua).

Lo que llama un "puerto de reenvío", que soluciona un problema tanto en una versión antigua como en una nueva, es una simple corrección o parche.


-1

No existe un término comúnmente usado para fusionar un conjunto de cambios de una rama de software anterior a una nueva. A menos que la última rama del software sea muy inestable, la mayoría de los desarrolladores desarrollarán correcciones de errores en la última rama del software, independientemente de la versión en la que se encontró el error. Esto se hace para reducir los conflictos de fusión ya que la última rama del software cambia con mayor frecuencia que las ramas más antiguas. Cualquier error de software informado por un cliente se informa, por definición, en una versión anterior a la que se corrige, ya que el cliente no tiene acceso a la última rama de su software.


cierto a menos que su cliente quiera una solución AHORA.
Alex R

-1

Vine aquí buscando una respuesta porque estoy escribiendo un comentario de confirmación para este mismo escenario. Dada la falta de jerga real para esta situación común, voy a explicarlo como "fusionar las revisiones de producción en la rama de desarrollo".

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.