google / google/codeworld

Set up separate servers for stable versus head

Abierto
#667 0 comentarios 0 reacciones 0 asignados Ver en GitHub
cleanup
Lenguaje dominante
Haskell
Estrellas
1.3k
Forks
201
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

I want to have two servers:

* **code.world** is the stable server, which is updated once per year some time in July.
* **alpha.code.world** (or something similar) is the head server, which is basically pushed on green.

Breaking API changes should go only to alpha.code.world, and then be released to the stable server on a set schedule. Bug fixes and non-breaking improvements could go to both servers at the same time. This means we'd also keep a separate branch of the code for the stable server.

Intended uses of the alpha server include:
* General use by those who don't mind occasional breaking changes. We would still follow deprecation cycles and such for this server, so it shouldn't be awful.
* Use by those who are preparing (teaching materials, learning themselves, etc.) for the release of these changes to the stable server.

We would encourage those who are teaching to use the stable server. This approximately captures the same pattern as @alphalambda has going on for his own server (though our stable server might have a different release schedule, since we probably want to make the switch in the summer to avoid breaking year-long classes).

Concerns:
1. Both servers need access to the same data, which means I finally need to move data to network storage (See #84)
2. I will need to learn more about using git, so I can be competent at merging changes between branches and such.

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

Comienza revisando la dependencia de almacenamiento de red de la issue #84 y la configuración actual de los servidores y las ramas del proyecto. Define cómo code.world y alpha.code.world comparten los datos, cómo se fusionan los cambios de stable y head, y cómo se gestiona el release estable anual. Se considera completado cuando ambos servidores tienen el comportamiento de release descrito y acceso compartido a los datos.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
git, haskell
Área
infrastructure, release
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.