Czy trzeba aktualizować wersję wtyczki, jeśli tylko aktualizujesz atrybut „Testowane do”?


12

Mam wiele wtyczek hostowanych na serwerze svn wordpress.org ... wraz z ogromną wersją 3.1 chciałbym zaktualizować metadane „Tested up”.

W kodzie nie będzie żadnych zmian funkcjonalnych, tylko metadane.

Czy konieczna jest zmiana numeru wersji dla tak trywialnej zmiany?

Odpowiedzi:


5

Zwiększę numer wersji tylko wtedy, gdy użytkownicy będą musieli ponownie pobrać wtyczkę. Zmienna „Testowane do” nie jest używana, gdy wtyczka jest zainstalowana, tylko wtedy, gdy ludzie chcą ją zainstalować lub chcą dokonać aktualizacji. W takim przypadku informacje i tak pochodzą z serwera, więc nie musisz wymuszać nowego pobierania wtyczki.

Oczywiście, jeśli twój readme.txtw trunkkatalogu ma Stable tagwskaźnik, powinieneś zaktualizować go readme.txtwe właściwym tagspodkatalogu, w przeciwnym razie zostanie zignorowany. Nie ma problemu z aktualizacją pliku w tagskatalogu i nie tworzeniem nowej wersji, ponieważ Subversion jest normalnym katalogiem, podobnie jak wszystkie inne, to tylko konwencja, aby używać go do oznaczonych wydań historycznych.


3

Sądzę, że inne odpowiedzi dokładnie wyjaśniły argumenty przemawiające za odrzuceniem Tested up toatrybutu i nie widzę w nich nic złego. Ponieważ nikt nie wymienił powodów, by tego nie robić, pomyślałem, że będę grał w adwokata diabła;)

  • Tagi są zamierzone i zakłada się, że są migawką programu w danym momencie. Edycja znacznika po naruszeniu konwencji, na których ludzie polegają podczas pracy z kodem. Potencjalne konsekwencje są wprawdzie niewielkie - jeśli nie nieistniejące - w tym konkretnym przypadku, ale wiele osób woli zająć purystyczne stanowisko w takich sytuacjach i zachować czystość. Właśnie dlatego niektórzy klienci SVN wydają ostrzeżenie, gdy użytkownik próbuje zatwierdzić zmiany w tagu.
  • Jako potencjalny użytkownik wtyczki, gdybym patrzył na dzienniki SVN i zauważył autora dokonującego zmian w oznaczonych wersjach, podejrzewałbym, że być może jego konto zostało zhakowane i ktoś próbował wprowadzić złośliwe oprogramowanie do najnowszej wersji, lub że autor nie był świadomy tego, jak działa kontrola źródła - a co za tym idzie, może nie być bardzo dobrym programistą - co sprawiłoby, że wahałem się przed pobraniem wtyczki.
  • Tracisz niektóre dane historyczne. Na przykład, jeśli chcesz wrócić rok później i śledzić zgodność wtyczki z najważniejszymi wydaniami, nie możesz przeprowadzić dokładnej analizy, ponieważ Twoje dane zostały uszkodzone.
  • Istnieje inny mechanizm osiągnięcia tego samego rezultatu. Repozytorium pozwala użytkownikom głosować na to, czy konkretna wersja wtyczki działa z określoną wersją rdzenia. Osobiście ufam tym danym bardziej niż stwierdzenie autora wtyczki.
  • Podejrzewam, że motywacją do takich rzeczy jest często własne ego autora i niepewność; chcą mieć pewność, że ich wtyczka wygląda „pomyślnie” i jest pobierana tak dużo, jak to możliwe. Często widzę takie zachowanie wśród autorów wtyczek i sam często odczuwam pokusę, ale myślę, że jest to niedojrzałe i niezdrowe, więc staram się temu przeciwstawić.

Radzę odpocząć i zostawić tagi w spokoju. Po prostu oddaj swój głos na „to działa” na stronie repo - oczywiście po serii testów - i zostaw to. Jeśli naprawdę martwisz się, że Twoja wtyczka wydaje się być aktywna, poświęć czas na pracę nad nowymi wersjami z poprawkami błędów, ulepszeniami bezpieczeństwa / wydajności / interfejsu użytkownika i przydatnymi nowymi funkcjami; nie trać czasu na martwienie się o to, co myślą inni ludzie i ile pobrań wtyczka otrzymała w zeszłym tygodniu.


1

Cóż, jeśli tylko aktualizujesz plik Readme, nie widzę powodu, aby zwiększać numer wersji. Jeśli używasz tylko pnia, możesz szybko zatwierdzić zmianę tej jednej rzeczy i nikt tak naprawdę nie zauważy, że używasz tagów. Myślę, że będziesz musiał utworzyć nowy tag (nie w 100% niezbyt dobrze zaznajomiony z svn ).


0

Myślę, że można śmiało powiedzieć, że to kwestia osobistego wyboru. Zamiast aktualizacji pełnej wersji (np. 1.0 do 2.0) możesz rozważyć wydanie 1.1.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.