Gogs el gestor de proyectos y repositorios git marco un antes y despues, pero debido a su conservador linea de desarrollo (menos commits estupidos para features) , nacio un paralelo llamado gitea, este ya dejo de ser su sombra, al no usar macarron como framework uno de lso proyectos base de la arquitectura gogs.
Anunciado oficialmente en la release 1.14 de gitea y desarrollado en el pull rquest # 14293 los desarrolladores de gitea (que siempre estan tan aburridos que le agregan mas cosas que el mismo gitlab a su gitlab) cambiaron el framework macarron a el framework chi
Para los mas entendidos en desarrollo web sobre golang, remitase a estos comparativas: https://github.com/diyan/go-web-framework-comparison#reviewed-libraries-and-frameworks
Esto separa totalmente gitea (el cual ya venia siendo mas gordo en features y opciones que gogs, incluso en configuraciones) de su padre gogs, el cual es mucho mas conservador y estable.
La version 1.14 ultima de gitea solo tiene esto como el mayor cambio significativo, ya la larga racha de "features estupidos" se esta acabando y empiezan a meter features de profundidad y verdaderamente utiles en los ultimos meses.
¿Gogs o gitea?
Particularmetne depende mas que todo de el objetivo:
Si desea tranquilidad y no andar siempre pendeinte de el sistema y tener una vida real, gogs, este solo se centra en servir un repo git en lo mas simple sin tanta fiesta, gogs y su desarrollador tiene la vision de simplicidad siempre.
Si desea mas cosas, y no tiene novia ni familia, necesita customizar de todo, gitea permite tener un sistema muy cercano a gitlab o github sin la complicacion del deploy (especialmente gitlab el cual es un dolor).
Razones que produjeron el cambio:
- Modelo de un mantenedor
- Escapes cuestionables y prácticas de seguridad anteriores
- Pánico en init si el directorio de trabajo no es legible (¡!)
- routes.go está escrito a mano y tiene que ser actualizado manualmente
- Fomenta la escritura manual de URLs lo que ata la forma de manejo
- El codificador JSON realmente almacena el objeto completamente en la memoria antes de generar la respuesta que también se almacena en la memoria antes de ser transmitida.
- El marco de traducciones (i18n) tiene una serie de problemas - el más grande es el requerimiento de listar qué idiomas están disponibles y si hay errores no hay soluciones a menos se regeneere.
- no hay manejador de compresion
- el manejo de sesiones debio ser reescrito
Claro hay que destacar que la mayoria de estas razones son especificas de los desarrollos atorrantes y apresurados de los desarrolladores, prefieren facilidad de codigo sacrificando requisitos en la complejidad de software
Conclusion:
Los creadores de gitea siempre fueron geeks mas que administradores, un admin no desea vivir metido en la maquina, tiene vida real, asi que esto solo es valido para los que desean jugar, lo cual es logico en el tipo de desarrollo que llevan pero perjudicial en el mantenimiento de administradores (constantes cambios).
No hay comentarios.:
Publicar un comentario