Opracowałem projekt, od czego zaczynają się moje numery wersji?

Rozwidliłem projekt i wiele go zmieniłem. Ten widelec to nie tylko mała zmiana funkcji tutaj i ukryta tam naprawa błędów, to dość istotna zmiana. Udostępniana jest tylko większość kodu podstawowego.

Rozwidliłem ten projekt w wersji 2.5.0. Od jakiegoś czasu zacząłem wersjonować swój widelec w wersji 3.0. Jednak nie jestem pewien, czy jest to właściwy sposób, głównie dlatego, że kiedy ten projekt trafi do wersji 3.0, sprawy stają się mylące. Ale nie chcę zaczynać od wersji 1.0 lub wersji 0.1, ponieważ oznacza to niemowlęctwo, niestabilność i brak refinansowania projektu. To nie jest prawda, ponieważ większość kodu podstawowego jest bardzo dopracowana i stabilna.

Naprawdę jestem zagubiony, co robić, więc pytam tutaj: Jaki jest standardowy sposób radzenia sobie z tego rodzaju sytuacją? Czy większość widelców zaczyna od nowa, podskakuje numery wersji lub robi coś innego, czego nie jestem świadomy.

Większość widelców, które widziałem, zaczyna się od wersji 1.0. Ale zakładam, że zmieniłeś także nazwę swojego widelca, więc nie jestem pewien, dlaczego wprowadziłbyś zamieszanie, gdybyś po prostu zaczął od wersji 3.0.

Chciałbym zmienić nazwę projektu, wydać wersję 1.0 i wyjaśnić, że projekt jest rozwidleniem innego projektu. Nie sądzę, aby było to mylące z tym podejściem.

Jeśli naprawdę martwisz się etykietą „1.0”, po prostu wypuść wersję 2.0 wkrótce po wersji 1.0 ...

Przygotuj własny plan i trzymaj się go, zaczynając od numeru oryginalnej wersji, ale nie próbuj ścigać się z bieżącą wersją oryginalnego produktu.

Możesz zastanowić się, czy (i ile) twój projekt będzie powiązany z pierwotnym. Jeśli planujesz przenieść nowe funkcje z oryginalnego projektu do swojego projektu, możesz rozważyć dopasowanie numerów wersji do wersji oryginalnej.

Jako przykład sprawdź MariaDB, która jest rozwidleniem MySQL. Chcą, aby był to „drop-in” zamiennik dla MySQL, więc na przykład MariaDB 5.2 ma wszystkie funkcje MySQL 5.2.

Zobacz: http://kb.askmonty.org/v/mariadb-versus-mysql

Uwaga: Od czasu opublikowania tej odpowiedzi MariaDB znacznie różni się od MySQL i teraz stosuje własny schemat wersjonowania.

0,1 może wskazywać na niemowlęctwo, ale wersja 1.0+ oznacza stabilną. Wzrost liczby głównych wersji, np. 2.0, 3.0, ogólnie wskazywał na dużą zmianę funkcji.

Na przykład

• Wersja 1.0 mojej aplikacji była narzędziem do uruchamiania skryptów testowych z instalatorem,
• Wersja 2.0 usunęła rozróżnienie między skryptami testowymi a skryptami konfiguracji środowiska,
• W wersji 3.0 dodano GUI do pisania skryptów jako schematów blokowych. Są to wyraźnie różne produkty, ale nawet wersja 1 była działającym produktem, całkowicie stabilnym itp. Powstały wersje 2 i 3, ponieważ zdecydowano, że te duże zmiany będą dobre. Gdybyśmy nie chcieli tych dużych zmian, i kontynuowalibyśmy naprawianie błędów, itp. Liczba małych wersji właśnie wzrosła, 1.10,1.20 itd. I byłoby dobrze.

Mówię, że główne numery wersji nie wskazują dojrzałości, wskazują na główne zestawy funkcji. To było trochę styczne od sposobu numerowania wersji produktu.

To, co widziałem wcześniej, co mi się podobało, to ponowne uruchomienie wersji od 1.0 (lub od 3.0, jeśli naprawdę wolisz), a następnie w nawiasach powiedziano, z której wersji oryginału ostatnio miały cechy.

• Początkowo: „ MyFork v1.1 (na podstawie OrigProg v3.0)
• Niektóre ulepszenia wprowadzone do MyFork: MyFork v1.3 (na podstawie OrigProg v3.0)
• OrigProg wydał główną wersję, a MyFork ściągnął i połączył: MyFork v2.1 (oparty na OrigProg v4.0)
• Wprowadzono kilka poważnych zmian w MyFork (prawdopodobnie już nigdy nie będzie można łatwo połączyć się z OrigProg): MyFork v3.0 (oparty na OrigProg v4.0)

Jeśli to możliwe, połącz widelec z powrotem do oryginalnego projektu. Nie mogę tego wystarczająco podkreślić.

Ponownie zarejestruj swoje numery wersji, a następnie użyj tego, który rozwidliłeś, oraz sufiksu daty.