Overhaul of the plugin maintenance/system

Abierto
#4,002 12 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
git, github, json

Línea de trabajo

Comienza con channel.json y los metadatos de los plugins en plugin-channel/plugins/.json y updated-plugins/**/.json; después, compara las estructuras de los releases y repositorios enlazados. Un resultado completo definiría el modelo de propiedad de los repositorios, las referencias de versión/tag, los enlaces a artefactos y los futuros campos de hash en los repositorios mencionados; el issue no identifica un punto de entrada para la implementación ni pruebas.

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

Descripción

feature
Description

This is a topic which spans over multiple repositories:

Current situation:
We have a lot of plugins which are currently "maintained" inside one single "large" updated-plugins repository, which are somehow old forks or the last "actual" state. On top of that we have plugin-channel which point to plugins inside updated-plugins or the upstream locations.
Both repositories have in common that they store the binary artifacts of every tracked version in one release...

channel.json points to...

Target situation:
Each plugin shall be tracked within one single repository, whether it's one of micro-editor or a third party.
Each version of each plugin must be tracked with its version number AND tag fitting together. Based on the tags GitHub will already create "snapshots" of the actual repository content, archive them to a zip and tar.gz, which then can be linked as artifact (actually no need to track further manually uploaded binaries/artifacts).
The *.json's pointing to the concrete files/versions should include (for future) revisions an entry for the hash of the file, to provide at least some sort of authenticity.
Unfortunately GitHub's tag snapshots don't generate a SHA256 on its own.

We need a plan where the master *.json is tracked and which location it shall point to.
I think we can agree, that the micro team can't maintain every possible plugin, but the question is, if it shall curate the plugins and point to fixed releases?

Lenguaje dominante
Go
Estrellas
29.8k
Forks
1.4k
Merge medio
1 d 12 h
PR fusionados (30 d)
2

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de micro-editor/micro

Todos los issues de micro-editor/micro

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.