Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

v4 -> v5 upgrade path

Abierto
#442 1 comentario 2 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
rust

Línea de trabajo

Comienza revisando la dependencia de Cargo y la configuración de compilación para boring-sys v4 y v5, especialmente la propiedad links y la dependencia opcional propuesta. Primero verifica el comportamiento una vez que v5 esté disponible en crates.io y después prueba la ruta de actualización usando boring v4 y boring-sys v5 conjuntamente. Se considera terminado cuando la versión de compatibilidad evita conflictos de links y conserva la funcionalidad de v4 compatible.

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

Descripción

v5

Cargo won't allow boring-sys v4 and boring-sys v5 coexist in one project (thanks to links property), which generally is a good idea, because their C symbols would conflict. However, this means that projects can't upgrade to boring v5 if any of their dependencies use boring v4. Such all-at-once upgrade is much harder and gets slowed down by the slowest-to-upgrade dependency.

It's relatively easy to make boring v5 support being used with boring-sys v4, but it's the less interesting combination, since the sys crate is more important to upgrade.

Unfortunately, making boring v4 use boring-sys v5 is more complicated. We can't simply release a version of boring v4 that accepts both versions of the sys crate, because the sys v5 crate has has only a subset of sys v4 functionality. cargo update eagerly picks the latest version of dependencies, so it would be a breaking change.

I can't simply use a feature flag as an opt-in to sys v5, because Cargo is overly restrictive with links, and wants to make a single universal Cargo.lock that takes into account even optional disabled dependencies.

Given the limitations, my current idea is to release a version of boring-sys v4 that doesn't have a links property, but optionally depends on boring-sys v5. Make it skip its own build and re-export v5 crate when a feature flag is enabled. This will be easier to test once v5 is on crates.io, so we should release v5 first.

Lenguaje dominante
Rust
Estrellas
526
Forks
178
Merge medio
15 h 34 min
PR fusionados (30 d)
9

Preparar el entorno

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 cloudflare/boring

Todos los issues de cloudflare/boring

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.