Gracias por los comentarios, veo que no he contado ninguna barbaridad y que más o menos pensamos igual ja ja ja
Contesto algunos de los puntos:
SeiTaN escribió:El ZIP de "channels" y "servers" saldrá directamente de develop, haremos algún tipo de script que lo mantenga al día.
Creación
Cada cuanto se hará? 1 o varios días, semanal, bisemanal?
Yo había pensado en un script que al final de cada día creara la actualización, si ha habido cambios en el git.
SeiTaN escribió:Actualización
¿Como se hará para actualizarse? es decir, en el addon te listará un directorio donde están todos los zips o sólo te mostrará un aviso del último que tú no tengas?
Entiendo que esta actualización podrá ser manual o automática e independiente de la del canal cuando se acceda.
La actualización del ZIP de canales será automática y silenciosa (con una notificación al terminar), aunque podrás desactivarla. Preguntar cada día por lo de "¿quieres instalar una actualización?" puede ser agotador para el usuario.
La actualización de canales individuales al entrar también será automática y silenciosa (con notificación al final), y también podrás desactivarla.
Luego en la opción de actualizar, que será algo así como una lista de todas las cosas que puedes hacer, sí que había pensado dejar todas las opciones: listar versiones e instalar las que quieras, listar ZIPs de canales e instalar el que quieras, etc. Pero en general la versión "antigua" de canales y conectores no tiene mucho sentido.
SeiTaN escribió:Referente a la actualización de los canales, ¿recuperamos el sistema de comprobación con los xml? lo digo para tenerlo en cuenta y tb modificarlos cuando se actualize o cree un canal.
Eso es, al entrar a un canal se irá a la URL que haya en el XML para ver si hay nueva versión. Opcional, como he dicho antes.
SeiTaN escribió:Sobre github Jesús al final vas a cambiar el tipo de cuenta o lo vas a dejar como hasta ahora?
Supongo que te refieres a lo de convertirla en una cuenta de organización... efectivamente lo haremos así.
Quiero agilizar el flujo lo más posible, por si vuelvo a tener una sobrecarga de trabajo como la de estos meses que podamos seguir avanzando sin que yo sea el bloqueo.
super_berny escribió:- El ZIP de "channels" y "servers" saldrá directamente de develop, haremos algún tipo de script que lo mantenga al día.
Github permite lanzar scripts al recibir un commit:
Hooks
Lo se, lo hemos comentado en alguna ocasión. No descartes que sea este el sistema, pero al principio lo haré manualmente.
super_berny escribió:Eso si, a la hora de enviar PR de canales/servidores y añadirlas a develop debemos ser muy escrupulosos. Deberian especificarse claramente si los cambios solo afectan aun determinado canal (por cambios en la web por ejemplo) o si ademas hemos modificado alguna otra cosa para añadir una nueva funcionalidad al canal y este deja de ser compatible con versiones anteriores. Me explico: Imaginaros q añado una nueva funcionalidad a pelisalacarta, por ejemplo añadir la BSO de las peliculas en los listados de peliculas y sus enlaces. Para demostrar q funciona modifico el canal ZZZZ, pero ahora esa nueva version del canal ya no funcionaria si lo copiamos en una version de pelisalacarta q no tubiese mis cambios. Pues bien, esta version del canal ZZZZ no deberia ir en el zip de actualizacion de canales.
Esto es fácil de resolver. Añadiremos en el xml del canal la versión mínima necesaria para que funcione, y si la versión que tienes es inferior ese canal no se actualizará ni podrás instalarlo ni te saldrá en el listado
super_berny escribió:jesus escribió:- Sólo pasaremos a "master" aquello que se vaya a incluir en la beta o en la versión final.
¿Que te parece si las betas tiran de la rama develop y las versiones finales de master? De este modo master SOLO se ha de actualizar (trayendo los cambios de develop) cuando se quiera publicar una version final.
Esa era mi idea hasta que me di cuenta de que en realidad no hay ninguna diferencia entre una beta o una final, excepto que no tenemos mucha confianza en que esté libre de fallos. De ahí que salgan de "master", y que no tengan un id de plugin diferente.
Podríamos perfectamente seguir publicando como hasta ahora, incrementando en +1 la versión y diciéndole a la gente que son versiones en continua evolución para que se atengan a las consecuencias.
Pero haciéndolo de este modo permitimos que sepan el grado de "estabilidad" que le concedemos a una versión (los usuarios cautos sólo instalarán la versión final, o las betas a partir de la 2) y además les dejaremos volver atrás.
Desde el punto de vista del GIT es lo mismo que hasta ahora.
Cmos escribió:Creo que lo suyo es que además, en el foro, se habilitara un tema único o un subforo para tratar específicamente los fallos o mejoras que se vayan viendo en las betas, porque sino puede ser un lío cada vez que nos pongamos a resolver una duda o un reporte de error.
Totalmente de acuerdo, y también tendríamos que abrir uno para las cosas que vayan a ir en cada versión y así coordinar esfuerzos como proponía Robalo.
Cmos escribió:Para el tema de los ZIP de canales y servers, yo planteo otra propuesta teniendo en cuenta, como bien ha dicho super_berny, que pueden llegar a haber canales que funcionen en una versión y no en otra porque modifiquen otros archivos del addon. La idea sería, como dice super, tener la rama develop para betas, y la master para la final y para las actualizaciones de canales y conectores que no dependan de otros cambios.
Cuando se abra un PR con algun update, indicar si no es compatible con cualquier versión, si es así solo se mergea en develop, y si no se dice nada, se hace en develop y master. Luego, para la actualización de los canales y servers en el addon, se puede hacer un script que compruebe al entrar si hay un nuevo commit en las carpetas correspondientes de la rama master, y si es así, se lanza el método addchannel del canal configuración pasándole la url de master (habría que hacerle una pequeña modificación para que no abriese el teclado). De esta forma no sería necesario tener que estar creando zips y además ese método realiza backups de los archivos, así que no sería dificil de reparar en caso de fallo.
Pensé mucho en esto y creo que es mejor mi opción de indicar la versión mínima en el XML del canal. Esto será algo excepcional, y por el flujo normal de uso poca gente tendrá problemas con esto.
Tú te instalas la 4.2.0, con un paquete de canales que funciona. Hasta que no salga la siguiente versión no recibirás nuevos canales (a menos que los añadas tú manualmente), y recibirás actualizaciones de tus canales hasta que el responsable del canal decida incrementar el número de versión mínima de su canal a la "4.2.1 beta 1" (por ejemplo).
El canal seguirá funcionándote, simplemente no se actualizará hasta que no subas la versión. El control de versiones de cada canal individual lo llevará cada usuario en su instalación
Aparte de que el usuario se pueda instalar versiones anteriores, y cosas por el estilo, ¿se os ocurre algún caso donde esto no resuelva el problema sin necesidad de basarlo en ramas de git?
y en segundo lugar como puedo saber yo en q numero de version se va a aceptar mi PR?