2012-03-16 7 views
7

¿Es posible actualizar manualmente el archivo deps para obtener la última versión de Doctrine 2.2? Me gustaría utilizar el nuevo componente Paginator. Así que, básicamente, yo estaba pensando que ajustar deps con:Actualizando manualmente el archivo deps de Symfony2 para obtener Doctrine 2.2?

[doctrine-common] 
    git=http://github.com/doctrine/common.git 
    version=2.2.1 

[doctrine-dbal] 
    git=http://github.com/doctrine/dbal.git 
    version=2.2.1 

[doctrine] 
    git=http://github.com/doctrine/doctrine2.git 
    version=2.2.1 

Retire deps.lock y hacer:

php bin/vendors update 

¿Cree que va a funcionar?

EDITAR: el archivo se vería así: http://pastebin.com/FEDMNhii

Respuesta

8

En mi opinión, todo el trabajo sugerido por gilden es innecesario y demasiado cauteloso. Por supuesto, puede actualizar manualmente su archivo deps con lo que desee. Actualmente estoy ejecutando Doctrine \ Common (2.2.1), Doctrine \ DBAL (2.2.1) y Doctrine (2.2.1) en Symfony 2.0.11 sin problemas.

No son las bibliotecas que usted necesita preocuparse acerca de (por lo general), que es el paquetes que utilizan las bibliotecas que requieren la versión específica (s). Por ejemplo, Symfony2 no tiene dependencia directa de ninguna versión de Doctrine, pero sí lo hace DoctrineBundle.

Antes de actualizar un paquete/biblioteca, generalmente es bueno verificar sus dependencias requeridas en Packagist.org. Busque el paquete que desea actualizar y vea qué dependencias requeridas definen. Nota: Esto no será necesario en Symfony 2.1, ya que utilizará Composer para administrar bibliotecas de proveedores.

Aunque nunca sabrá si algo funciona con su instalación o no, a menos que lo intente. Por supuesto, no hagas nada estúpido, pero no hay razón para temer romper cosas actualizando las bibliotecas de los proveedores. Almacene su código en Git y puede revertir fácilmente sus cambios.Ver: How to create and store a Symfony2 project in Git


Asimismo, al especificar version=#.#.# en deps - incluso si usted no tiene un archivo deps.lock en absoluto, siempre obtendrá el mismo hash de cometer debido a que está especificando la etiqueta Git en el repositorio.

Algunos paquetes, en lugar de proporcionar números de versión, ofrecerán varias ramas para gestionar la compatibilidad con múltiples versiones de Symfony. Por lo tanto, es posible que vea algo como version=origin/2.0, lo que significa que la secuencia de comandos del proveedor procesará la última confirmación en la rama denominada 2.0 del repositorio. El mantenedor probablemente intente mantener esa rama siempre compatible con Symfony 2.0.x.

+0

Tan buena explicación, +1. Por cierto, cuando Symfony 2.1 estará disponible? – gremo

-1

Al eliminar el archivo deps.lock obviamente estás poniendo en riesgo a conseguir código inestable.

he utilizado las siguientes medidas para minimizar el riesgo de romper algo:

  • Anote la corriente cometer hash de los componentes desea actualizar desde deps.lock
  • Encuentre el hash de confirmación desde GitHub y anótalo
  • Navegue hasta el directorio de un componente y escriba git checkout [commit] donde [commit] es el nuevo hash.
  • Borre su caché y verifique que el sitio aún funcione más o menos.
  • pegue el nuevo hash de comprometerse a deps.lock y ejecutar bin/vendors install

Tenga en cuenta que yo les recomiendo vivamente contra esta. Si te equivocas, estás más que solo y no hay nadie para ayudarte.

+0

Gracias hombre. Hice una prueba rápida en una instalación nueva y todo parece estar bien (generación de entidades, consultas, etc.). Pero nuevamente gracias por el consejo. – gremo

+1

por qué no simplemente guardar deps y deps.lock (o usar git) y en caso de que algo se rompa, revertir los cambios y actualizar nuevamente a los proveedores. Debería descargar todo lo especificado en deps.lock? – Sgoettschkes

+0

Acepto que este consejo parece ser excesivamente prudente y complicado cuando deps.lock se puede guardar y restaurar en caso de desastre. – user1207727

Cuestiones relacionadas