2015-03-27 16 views
18

W projektach maven wersja projektu znajduje się w <version> attritbute pliku pom.xml. Podczas tworzenia nowej wersji w modelu przepływu Git muszę podać numer wersji. This article wyjaśnia, jak to zrobić (bez Maven):W jaki sposób należy zaktualizować wersję wewnątrz mojego pom.xml podczas zwalniania za pomocą przepływu git?

  1. Tworzenie oddziału zwalniającą
  2. zmienić numer wersji i zobowiązać
  3. Merge gałąź uwalniania zarówno do rozwijania i mistrza

dodatkowo mówi:

To właśnie na początku gałęzi wydania zostanie nadane nadchodzące wydanie numer wersji - nie wcześniej. Do tego momentu gałąź rozwijająca odzwierciedliła zmiany w "następnym wydaniu", ale nie jest jasne, czy "następne wydanie" ostatecznie stanie się 0.3 lub 1.0, dopóki gałąź wydania nie zostanie uruchomiona. Decyzja ta jest podejmowana na początku oddziału wydania i jest przeprowadzana zgodnie z zasadami projektu dotyczącymi wstawiania numeru wersji.

Widzę dwa problemy w połączeniu z Maven tutaj:

  1. Wersja w rozwoju w Maven byłoby [nowa wersja] -SNAPSHOT. Nie możemy więc odłożyć decyzji, która wersja jest następna, aż do momentu utworzenia gałęzi wydania. Oczywiście, jeśli później możemy zmienić zdanie, ale musimy już wcześniej wpisać/jakąś wartość/tutaj.
  2. Przed stworzeniem naszego wydania wersję w pom.xml powiedzmy 1.1-SNAPSHOT. Teraz zmieniliśmy to po prostu na 1.1 w gałęzi wydania i połączyliśmy to z masterem. W porządku. Ale powinniśmy również połączyć tę gałąź z powrotem, aby się rozwinąć i do tego potrzebujemy dostosować wersję do np. 1.2-SNAPSHOT. I prawdopodobnie nie powinniśmy tego robić w gałęzi wydania, ponieważ to zatwierdzenie nie powinno być częścią wydania. Właściwie powinniśmy byli dokonać tej zmiany zaraz po rozwinięciu, ponieważ wszystkie przyszłe zobowiązania będą rozwijane w następnej wersji.

Podczas szukania problemu znalazłem kilka artykułów na temat wtyczek, które mogą zautomatyzować proces, co może być interesujące, ale to naprawdę dotyczy tego, jak powinien wyglądać wykres git i gdzie zatwierdza się jego wersja. być i nie w jaki sposób mogę zautomatyzować to za pomocą wtyczki maven.

+0

1) Tylko ++ do wersji. 2) Połącz, aby opracować, a następnie zmienić wersję. I użyj jakiejś wtyczki gitflow maven, byłoby to znacznie lepsze niż robienie tego ręcznie. –

Odpowiedz

4

Należy pamiętać, że Git został opracowany dla jądra systemu Linux, który ma własne reguły dotyczące wersji.

Dla Mavena powinieneś utworzyć gałąź wydania, która otrzyma migawkową wersję następnej wersji. Ta zmiana powinna być pojedynczym zatwierdzeniem (to jest po prostu zmiana numeru wersji w pom.xml). Podczas łączenia, że ​​kasa master i używać git merge --strategy=ours <release-branch>

--strategy=ours oznacza: Zrób seryjnej mówiąc „wszystko w master został poprawnie połączone z branży uwalnianiu”; nie wprowadzono żadnych zmian do opanowania. Następnie, Git potraktuje gałęzie jako scalone (to jest bez żadnych zmian) pomimo odmiennego numeru wersji w obu gałęziach.

Aby uniknąć wszelkiego rodzaju problemów podczas budowania master z Maven, należy użyć nieparzystej lub bardzo wysokiej wersji, która nigdy nie zmienia się jak 99.DEV-SNAPSHOT.

Po opublikowaniu wersji usuń wersję -SNAPSHOT z wersji w gałęzi wydania i zatwierdz. Po tym, ty kasie mistrz i scalić jeszcze raz z --strategy=ours.

+1

słowo ostrzeżenia ... musisz połączyć (lub czipować) wszelkie poprawki błędów do opanowania przed zrobieniem wersji programu maven. Jedyną różnicą między gałęzią wydawniczą a wzorcem muszą być numery wersji. –

0

Z Maven powinieneś nie zmienić ręcznie numeru wersji.

Powinieneś dodać informację "scm" do swojego pom, aby pozwolić Mavenowi zatwierdzić i popchnąć zmianę wersji bezpośrednio.

Następnie użyj "wtyczki wydania". Wykona to za ciebie. Załóżmy, że bieżąca wersja to "1.1-SNAPSHOT", zadanie "release: perform" będzie:

  • Zmień wersję na 1.1, zatwierdz, oznacz tę wersję i wciśnij.
  • Zmień wersję ponownie na 1.2-SNAPSHOT (lub 1.1.1-SNAPSHOT, 2.0-SNAPSHOT ... możesz wybrać następną wersję), zatwierdz i naciśnij.

Oto wyciąg z historii git na projekt, w którym używany jest plugin uwolnienia Maven:

* 2345678 - Normal developpement commit (on branch 1.2-SNAPHOT). 
* 5678901 - [maven-release-plugin] prepare for next development iteration 
* 89- (tag: 1.1) [maven-release-plugin] prepare release 1.1 
* 1234567 - Normal developpement commit (on branch 1.1-SNAPHOT). 

Uwaga 1: W momencie zwolnienia, trzeba przepisu kolejną wersję (1.2 ten przykład). Jeśli zmienisz zdanie, możesz zmienić to później. Wtyczka Maven "version: set-version" pozwala na ponowne przypisanie wersji całej hierarchii projektu. Musisz tylko zatwierdzić tę zmianę wersji przed następnym wydaniem.

Uwaga 2: W momencie wydania można również zmienić wersję wydania. Nawet jeśli obecna wersja to 1.1-SNAPSHOT, możesz zdecydować, że wydanie to wersja 2.0, a następna wersja rozwojowa to 2.1-SNAPSHOT.

+2

Wtyczka do wydania Maven nie działa z gitflow. –

+0

Podczas korzystania z Maven konwencje nazewnictwa wersji są dużym ograniczeniem (w przypadku użycia z repozytorium artefaktów stażystów). Dlatego wolę używać konwencji Maven/wtyczek do zarządzania projektem i dostosowywania gitflow do tych ograniczeń Mavena. Po przetestowaniu kilku możliwych opcji uważam, że jest to najlepszy kompromis. –

2

Dla normalnych wydań, po prostu zrobić gulę wersji snapshot po scaleniu oddział wydaniu:

  1. utworzyć oddział zwalniającą od develop i usuwania zrzut z wersji
  2. Merge go do master
  3. Merge to do develop
  4. Zmień wersję na develop na następną wersję migawki
  5. Naciśnij przycisk th master i develop

Jak wcisnąć wszystkie zmiany w tym samym czasie, zespół będzie zobaczyć tylko wzrost wersji snapshot.

Dla poprawek nie jest to możliwe, ponieważ tworzy się go z gałęzi master. W tym scenariuszu jest obejście, oto przykład użycia surowych poleceń git.

Przykład: Masz 1.0.0 na master i chcesz utworzyć wersję poprawki 1.0.1. Twój rozwój jest już pod numerem 1.1.0-SNAPSHOT.

  1. git checkout master
  2. git checkout -b hotfix/1.0.1
  3. Dokonaj poprawki!
  4. mvn versions:set -DnewVersion=1.0.1
  5. git commit -a -m "hotfix release 1.0.1"
  6. git checkout master
  7. git merge hotfix/1.0.1 (łatwe, ponieważ stworzyliśmy oddział off master)
  8. git checkout develop
  9. mvn versions:set -DnewVersion=1.0.0
  10. git commit -a -m "workaround to avoid merge conflicts"
  11. git merge hotfix/1.0.1 (będzie działać ze względu na wcześniej popełnić)
  12. mvn versions:set -DnewVersion=1.1.0-SNAPSHOT
  13. git commit -a -m "set version back to 1.1.0-snapshot"

Nie bardzo ładne, ale to działa. To rozwiązanie jest również używane przez jgitflow (wtyczka Maven wspierająca cię z przepływem git).

Powiązane problemy