Zapomnij o tym, co mówi Perl Best Practices. Nie jest to Biblia, a jedynie sugeruje użycie słów kluczowych RCS, ponieważ w tamtym czasie nikt nie myślał o innych systemach kontroli źródła. Twoim celem nigdy nie powinna być zgodność z konkretną implementacją PBP, ale dostosowywanie pomysłów w PBP do twojej własnej sytuacji. Pamiętaj, aby przeczytać pierwszy rozdział tej książki.
Najpierw naprawić swoje założenia:
Nie trzeba osobną wersję dla każdego modułu w dystrybucji. Musisz tylko nadać każdemu plikowi modułu wersję, która jest inna niż w poprzednich dystrybucjach. Każdy moduł w dystrybucji może mieć tę samą wersję, a kiedy to zrobi, wszystkie mogą być większe niż wersja z ostatniej dystrybucji.
Dlaczego ręcznie nie zmieniać wersji szybko zmieniającego się modułu?Powinieneś mieć określone punkty, w których twój kod staje się czymś, z czego ludzie mogą korzystać. W tych kwestiach robisz coś, aby powiedzieć, że podjąłeś decyzję, że twój produkt pracy powinien zostać rozpowszechniony, czy to jako test, czy stabilny. Zmieniasz wersje jako sposób informowania ludzi o swoim rozwoju. Kiedy pozwolisz, aby system kontroli źródła zrobił to tylko dlatego, że popełniłeś błąd, tracisz szansę na oznaczenie cykli w swoim rozwoju. Na przykład zwykle używam dwóch mniej ważnych wydań. Oznacza to, że dostaję 100 wydań, zanim kompilacja wyjdzie z wack i muszę wybić główną wersję, aby przywrócić prawidłową kolejność sortowania. To za mało miejsca w wersji, jeśli pozwolę, aby VCS sobie z tym poradził.
Użyłem słów kluczowych RCS do połączenia wersji moich modułów z ich numerem meldunku lub wersji, ale nigdy tak naprawdę się nie podobało. Wykonuję wiele commitów do pliku, zanim będzie on gotowy do następnej wersji, i nie potrzebuję zmiany, tylko dlatego, że poprawiłem błąd w dokumentacji. Będą duże skoki w numerach wersji, ponieważ wprowadziłem wiele drobnych zmian.
Teraz po prostu zmieniam wersje wszystkich moich plików modułów, kiedy jestem gotowy do wydania nowej dystrybucji. Używam ppi_version zmienić wszystkie wersje na raz:
ppi_version change 1.23 1.24
Wszystkie moje pliki modułu uzyskać ten sam $VERSION. Nie muszę używać $VERSION, aby je odróżnić, ponieważ używam do tego zwykłych funkcji kontroli źródła. Nie potrzebuję $VERSION, aby powiązać go z konkretnym zatwierdzeniem.
Jeśli pracuję nad nową dystrybucją z wersji 1.23, zaczynam tworzyć wersje rozwojowe 1.23_01, 1.23_02 itd., Ale tylko wtedy, gdy jestem gotowy, aby umożliwić ludziom wypróbowanie tych wersji. Zmieniam wersję na początku cyklu, a nie koniec. Wszystkie moje zatwierdzenia prowadzące do następnego wydania mają już następną wersję. Robię także notatki o tym, co chcę osiągnąć w tym cyklu.
Kiedy myślę, że to początek nowego cyklu, ponownie wybieram wersję. Kiedy wydaje mi się, że mam stabilną wersję, zmieniam wersję $VERSION na stabilną, np. 1.23_04 na 1.24. Ilekroć coś wypuszczam, oznaczam to również w kontroli źródła. Widzę, że moje główne punkty rozwoju są dość łatwe w dopasowaniu do źródła.
W ten sposób wszystko jest dla mnie łatwiejsze. Nic nie jest powiązane z kontrolą źródła, z której zdecyduję się korzystać, więc nie muszę przerabiać wszystkiego, jeśli zmienię to, czego używam.
To jest dobre pytanie. Ale czy Perl :: Critic i/lub PBP naprawdę polecają numery wersji RCS? AFAI, naprawdę nie obchodzi ich, skąd pochodzą te liczby. – innaM
@Manni: tak, nie przejmują się, ale nadal polecają RCS jako "najlepszą praktykę": "Powszechną praktyką jest użycie słowa kluczowego $ Revision: 3629 $, aby automatycznie zdefiniować zmienną $ VERSION w następujący sposób: nasz ($ VERSION) = '$ Wersja: 3629 $' = ~ m {\ $ Wersja: \ s + (\ S +)} x; " –
Ja współczuję, ponieważ jestem obecnie w dokładnie tej samej sytuacji. Domyślam się, że wraz z coraz większą liczbą projektów wykorzystujących git, praktyka będzie coraz mniej powszechna. – innaM