2012-03-16 7 views
7

Czy można ręcznie zaktualizować plik deps, aby uzyskać najnowszą wersję Doctrine 2.2? Chciałbym użyć nowego komponentu Paginator. Więc w zasadzie myślałem Wykręcanie deps z:Ręczne aktualizowanie pliku deponacji Symfony2 w celu uzyskania 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 

Usuń deps.lock i zrobić:

php bin/vendors update 

Myślisz, że będzie działać?

EDIT: plik może wyglądać następująco: http://pastebin.com/FEDMNhii

Odpowiedz

8

Moim zdaniem, wszystkie prace sugerowane przez gilden są niepotrzebne i zbyt ostrożne. Oczywiście możesz ręcznie zaktualizować swój plik deps w dowolne miejsce. Aktualnie używam Doctrine \ Common (2.2.1), Doctrine \ DBAL (2.2.1) i Doctrine (2.2.1) na Symfony 2.0.11 bez problemów.

Nie ma biblioteki, które trzeba martwić się (zazwyczaj), to jest wiązki że wykorzystują bibliotek, które wymagają określonej wersji (y). Na przykład Symfony2 nie ma bezpośredniej zależności od żadnej wersji Doctrine - ale robi to DoctrineBundle.

Przed uaktualnieniem pakietu/biblioteki zwykle dobrze jest sprawdzić wymagane zależności na Packagist.org. Wyszukaj pakiet, który chcesz uaktualnić i zobacz, jakie wymagane zależności definiują. Uwaga: Nie będzie to wymagane w Symfony 2.1, ponieważ będzie używać Composer do zarządzania bibliotekami dostawców.

Chociaż nigdy nie wiadomo, czy coś działa z instalacją, chyba że ją wypróbujesz. Oczywiście nie rób niczego głupiego - ale nie ma powodu, aby bać się łamania rzeczy, aktualizując biblioteki dostawców. Zapisz swój kod w Git i możesz łatwo przywrócić swoje zmiany.Zobacz: How to create and store a Symfony2 project in Git


Ponadto, przy określaniu version=#.#.# w deps - nawet jeśli nie ma pliku deps.lock w ogóle, będzie zawsze taki sam hash popełnić, ponieważ jesteś podając tag Git na repozytorium.

Niektóre pakiety, zamiast dostarczać numery wersji, będą oferować różne gałęzie do zarządzania kompatybilnością z wieloma wersjami Symfony. Możesz więc zobaczyć coś takiego jak version=origin/2.0, co oznacza, że ​​skrypt dostawcy wyśle ​​ostatnie zatwierdzenie do oddziału o nazwie 2.0 repozytorium. Opiekun najprawdopodobniej postara się, aby ta gałąź była zawsze zgodna z Symfony 2.0.x.

+0

Dobre wyjaśnienie, +1. Przy okazji, kiedy Symfony 2.1 będzie dostępne? – gremo

-1

Usuwając plik deps.lock jesteś oczywiście narażasz się na ryzyko w celu uzyskania kodu niestabilny.

Użyłem następujące kroki, aby zminimalizować ryzyko czegoś zrywającą:

  • zanotować aktualny popełnić mieszania składników, które chcesz zaktualizować z deps.lock
  • Znajdź hash popełniania od GitHub i zapisz to.
  • Przejdź do katalogu komponentu i wpisz git checkout [commit] gdzie [commit] to nowy skrót.
  • Wyczyść pamięć podręczną i sprawdź, czy witryna działa jeszcze mniej lub bardziej.
  • Wklej nowy popełnienia hash do deps.lock i uruchomić bin/vendors install

Pamiętaj, że ja zdecydowanie odradzam to. Jeśli zepsujesz sytuację, jesteś prawie sam i nie ma nikogo, kto mógłby ci pomóc.

+0

Dziękuję człowieku. Zrobiłem szybki test na świeżej instalacji i wszystko wydaje się w porządku (generowanie jednostek, zapytania itp.). Ale znowu dzięki za radę. – gremo

+1

dlaczego nie po prostu zapisać deps i deps.lock (lub przy użyciu git), a na wypadek, gdyby coś się zepsuło, powracasz do zmian i ponownie aktualizujesz sprzedawców. Powinien pobrać wszystko zgodnie z opisem w deps.lock? – Sgoettschkes

+0

Zgadzam się, że ta rada wydaje się zbyt ostrożna i skomplikowana, gdy deps.lock można zapisać i przywrócić w przypadku katastrofy. – user1207727