QGIS 3.0 – Cómo, cuándo y qué; implica

Muchos nos estamos preguntando:

¿cuándo se va a liberar QGIS 3.0?

El año pasado (2015) el equipo del proyecto comenzó a investigar cuándo y cómo se iba a liberar QGIS 3.0. Prometieron, de acuerdo a un post de Anita Graser, que iban a transmitir claramente a los usuarios y desarrolladores de sus planes antes de hacer el lanzamiento de QGIS 3.0.   Recientemente han tratado de exponer algunas de las consideraciones para un lanzamiento de QGIS 3.0 y al final del post hay una oportunidad para que podamos presentar nuestras ideas.

¿Por qué 3.0?

Normalmente una versión principal está reservado para los tiempos cuando se hace un gran cambio a la API de su software.  Este rompimiento no es una decisión trivial para el proyecto QGIS ya que somos cientos de miles de usuarios que dependemos de QGIS, tanto para uso propio como para servicio prestado a terceros.

De vez en cuando romper el API es necesaria para dar cabida a la actualización de la arquitectura con la mejora de los enfoques, nuevas bibliotecas y correcciones a decisiones cometidos en el pasado.

¿Cuáles son las consecuencias de romper el API?

Una de las razones por las que este rompimiento de la API en QGIS 3.0 es que va a tener un gran impacto, lo que podría romper los cientos de plugins desarrollados que ya no serían compatible con la nueva API y los autores de estos tendrían que hacer una revisión de sus desarrollos para asegurar compatibilidad con la nueva API.

La amplitud de los cambios necesarios depende en gran medida de:

• Cuántos cambios a la API afectan la funcionalidad actual.
  En cuántos puntos los autores de plugins han utilizado partes de la API que cambiaría.

• ¿Cuáles serán los principales cambios para 3.0?

Hay cuatro áreas clave que se está buscando cambiar en 3.0:

Actualización Qt4 hacia QT5: Este es el conjunto básico de las bibliotecas en la que QGIS está construido en top level, hablamos del nivel CORE-funcional de la plataforma. El QT también proporciona bibliotecas para llevar a cabo la gestión de momoria, operaciones de conectividad y la gestión de gráficos.  El Qt4 (en el que QGIS se basa actualmente) por ahora no está siendo desarrollado por los responsables de la biblioteca Qt y podría tener problemas en cuanto a funcionalidades con algunas plataformas (por ejemplo, OS X) e inclusive facilitar la gestión de versiones binarias (por ejemplo Debian Testing y la próxima versión de Debian “Stretch”). El proceso de llevar QGIS a QT5 ya tiene un avance importante (principalmente lo que ha hecho Matthias Kuhn) que junto con Marco Bernasocchi fuman sobre el Android “QField” basado totalmente en QT5. Sin embargo, hay algunas limitaciones en poner en marcha la nueva QT5 por su impacto en QGIS – en particular con los widgets de navegadores web (utilizados principalmente en el Composer y también algunos otros lugares en QGIS).

Actualización PyQt4 a PyQt5: Estos son los cambios relativos al lenguaje Python para Qt en la que se basa la API Python de QGIS. Se plantea cambiar la biblioteca de QT5 C ++, también se espera trasladar a la biblioteca python a PyQt5 para que se puedan sacar provecho a las bondades de la nueva API QT5 en Python.
Actualizando Python 2.7 a Python 3: Actualmente todo corre sobre Python 2.7.  Python 3 es la última versión de python y es recomendado por quienes lideran aquel proyecto. Python 2 es ligeramente incompatible con Python 3 (en una medida casi proporcional a la incompatibilidad que habrá entre QGIS 2 y Qgis 3). Muchos desarrolladores han hecho python Python 3 en gran medida compatible con versiones anteriores de Python 2, pero la compatibilidad en sentido inverso no es tan buena.
La mejora de la propia API de QGIS: Uno de los problemas con los que mantiene la compatibilidad API entre versiones es que hay que vivir con sus opciones de diseño para un largo plazo. En QGIS se hace todo lo posible para no romper la API dentro de una serie de lanzamientos de menor importancia.   Liberar una versión QGIS para 3.0 con una API no compatible con lo actual dará una oportunidad de “limpiar la casa” mediante la fijación de las cosas en la API que estamos con la que hay inconformidad. Se puede ver una lista provisional de los cambios propuestos para la API 3.0.

Cómo soportar el cambio de la API 3.0

Como ya se mencionó, la versión 3.0 se provocará una ruptura con la versión 2.x de QGIS y existe la posibilidad de que muchos plugins, aplicaciones existentes y otros códigos que se basan en la API actual se rompan.  Entonces, ¿qué se puede hacer para mitigar los cambios? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias y otros desarrolladores principales han estado buscando maneras de mitigar el número de cambios de ruptura API mientras sigue avanzando el código base QGIS estar basado en la próxima generación de bibliotecas y su propia API interna. Durante nuestra última reunión del Comité Directivo del Proyecto QGIS se geofumó a través de diversas posibilidades. La siguiente tabla resume lo que gentilmente resumió Matthias Kuhn y que en parte hemos intentado transliterar en este artículo acorde a lo que publicaron en su blog:

Hay dos cosas importantes a tener en cuenta sobre la propuesta de Matías:

En la primera fase, el trabajo se hace en la serie 2.x para completar el apoyo a QT5, PyQt5, usando Python 3.0, apoyando a Qt4, PyQt4 y Python 2.7. Esto implica que todos los cambios realizados en la primera fase serían compatibles con las versiones 2.x anteriores. Se incorporarán funcionalidades de Python se introducirán de forma que la antigua API PyQt4 todavía puede ser utilizado sobre todo cuando se compila contra QT5, PyQt5, Python 3.0. Al usar QGIS compilados contra Qt4, PyQt4 y Python 2.7 no habría ruptura compatibilidad.
En la segunda fase, se trabajaría para producir QGIS 3.0, introduciendo la nueva API, la se eliminará totalmente Python 2.7, incluido el soporte para Qt4 y PyQt4. Las nuevas funcionalidades de python que se introduzcan en la primera fase se mantendrán, teniendo en cuenta que todo el código python y desarrollos para versiones 2.x de QGIS continuarán trabajando en las versiones 3.x de QGIS. En esta fase se espera también introducir los cambios en la API QGIS que puede romper algunos plugins. Para hacer frente a esto se va a a proporcionar una guía de migración para tratar de facilitar el proceso de migración de las versiones 2.x QGIS a las versiones 3.x QGIS.

Caveat emptor

Hay un par de trucos que se deben plantear para asegurar que la migración a QGIS 3.0 suene menos doloroso.

• 1.  Se debe destacar que mientras que el enfoque establecida arriba trata de minimizar la cantidad de trabajo existente en scripting sobre python en los plugins, esto no será necesariamente en un 100% .  Habrá muy probablemente los casos en que el código tiene que ser ajustado y en todos los casos al menos, es probable que tenga que ser revisado con el fin de asegurarse de que sigue funcionando correctamente.
  2.  No existe recurso financiero formalmente establecido para pagar a los desarrolladores que invierten voluntariamente su tiempo para este proceso de migración. Debido a esto, va a ser muy difícil dar plazos exactos de cuánto tiempo tomará cada parte del proceso. Se debe tomar en cuenta esta incertidumbre en la planificación. Por supuesto se abre la bienvenida a donaciones para ayudar a que esto suceda.
  3.  Puede haber desarrolladores e instituciones por ahí que están financiando nuevas características para la serie 2.x QGIS y esto puede afectar su trabajo. Hay que incluir en los planes y presupuestos de estos proyectos, cierta asignación para hacer frente a la migración a la plataforma 3.x de QGIS.
  4.  Si el equipo de QGIS trabaja sobre sobre un “cambio total”, habrá un tiempo relativamente corto durante el cual QGIS estará inestable y en constante cambio debido a las actualizaciones en curso hacia QGIS 3.0.
  4.  Si se desarrolla de manera “evolutiva”‘, se corre el riesgo de que el desarrollo 3.0 puede llevar más tiempo a menos que haya un grupo fiel de los desarrolladores que trabajan sobre esto y conseguir que esté  listo para migrar.

  Propuestas

A la luz de toda la información anterior, se propone una de las dos líneas de acción:

Propuesta 1:

Liberar una versión provisional 2.16 y luego comenzar a trabajar en la versión 3.0 como prioridad, con una ventana de desarrollo de 8 meses. Los cambios hechos en la  versión 2.16 buscarán ser compatibles con la versión 3.0 (ver python3 / pytq5).

Propuesta 2:

Lanzarse de una vez a 3.0 con una ventana de duración más extendida sobre QT5, Python 3.0 y PyQt5 y, pedir a los desarrolladores hacer su trabajo en 3.0. Continuar con las versiones 2.x con la frecuencia habitual hasta que 3.0 esté lista.

Propuestas alternativas

¿Tiene una propuesta alternativa? A QGIS le interesa saber de posibles alternativas.  Si desea presentar una propuesta, por favor enviar a tim@qgis.org con el asunto “QGIS 3.0 Proposal”.

Conviene seguir el blog de QGIS, de donde salió esta publicación.