Czego użyć jako wersji początkowej? [Zamknięte]

Zwykle zaczynam projekty od wersji 1.0.0. Jak tylko mam kilka rzeczy razem, wypuszczam go jako 1.0.0 i przechodzę do 1.1.0.

Prowadzi to jednak do użytecznej, ale nie do końca funkcji pełnej wersji 1.0.0 większości rzeczy, które piszę. Następnie dodaję funkcje i przechodzę do przyzwoitej wersji gdzieś w okolicach 1.6.0. Wiele projektów zaczyna się od wersji 0.1.0, która będzie równie użyteczna jak moja 1.0.0.

Co byś zasugerował? Zacząć od 1.0.0 czy 0.1.0?

Ostatnia liczba dotyczy tylko wydań poprawek błędów. Możesz myśleć o mojej wersji 1.0.0 jako 1.0, a 0.1.0 jako o 0.1 jest dla ciebie łatwiejsza.

Moje przechowywanie wersji zależy od konfiguracji. Chcę, aby zastępował starsze wersje, więc zwiększam go w skokach, które mają dla mnie sens.

Czasami jednak wersjonowanie jest sterowane przez klienta, szczególnie jeśli publikujesz kod.

Jeśli to Twoja decyzja, zrób wszystko, co najbardziej Ci odpowiada. Miałem problemy z wersjami wcześniejszymi niż 1.0, więc zaczynam od tego.

Standard Semantic Versioning 2.0.0 mówi:

Najprostszą rzeczą do zrobienia jest uruchomienie pierwszej wersji rozwojowej w wersji 0.1.0, a następnie zwiększanie wersji pomocniczej dla każdego kolejnego wydania.

Dobrze jest przejść z 0.3.0 prosto do 1.0.0. Równie dobrze jest być na poziomie 0,23,0. Począwszy od wersji 0.4.0 jest raczej niewskazane, ponieważ sugeruje, że były już opublikowane wersje.

Dodatkowo pamiętaj, że 0.y.zjest to odkładane na bok dla szybkiej iteracji, więc początkowy rozwój (a tym samym wiele istotnych zmian) nie pozostawia cię w czymś głupim, jak 142.6.0. Zamiast wpychać wersję główną, podbijaj wersję pomocniczą przy każdej istotnej zmianie, aż do wydania 1.0.0:

Wersja główna zero (0.yz) jest przeznaczona do początkowego rozwoju. W każdej chwili wszystko może się zmienić. Publicznego interfejsu API nie należy uważać za stabilny.

Numer wersji zależy wyłącznie od Ciebie. Rób to, co ma dla Ciebie sens i bądź konsekwentny. Nikt nie mówi, że musisz zaczynać od 0 lub 0,0, lub 1,0 lub 1,1.

Wielcy programiści używali systemu numerowania wersji jako lokalnych żartów. Przykłady (Wikipedia):

Od wersji 3 TeX używa idiosynkratycznego systemu numerowania wersji, w którym aktualizacje są wskazywane przez dodanie dodatkowej cyfry na końcu przecinka, tak że numer wersji asymptotycznie zbliża się do π. Jest to odzwierciedleniem faktu, że TeX jest teraz bardzo stabilny i przewiduje się tylko niewielkie aktualizacje. Bieżąca wersja TeX to 3.1415926; Ostatnia aktualizacja miała miejsce w marcu 2008 r

Dla METAFONT:

Metafont ma system wersjonowania podobny do systemu TeX, w którym liczba asymptotycznie zbliża się do e z każdą wersją.

Wreszcie, niezupełnie numer wersji, ale równie interesujący, jest to, że pierwsza oferta publiczna Google (IPO) została złożona w SEC w celu zebrania 2 718 281 828 dolarów (zauważ, że e ~ 2,718 281 828).

Chodzi mi o to: nie myśl, że musisz podążać za tłumem. Bądź kreatywny i konsekwentny.

Myślę, że w grę wchodzą tu różne czynniki. Należy wziąć pod uwagę psychologiczny / marketingowy wpływ numeru wersji (często zwiększany numer wersji => więcej $$$, ludzie nie chcą kupować wersji beta 0,99 itd.). Numery wersji „Logic” mogą pomóc w pracy w dużym zespole.

I podoba mi się sposób, w jaki Linux ma liczby nieparzyste dla wersji niestabilnych i liczby parzyste dla wersji stabilnej.

Kiedy otrzymuję pierwszą gotową do użycia, ale nie pełną wersję, zwykle próbuję ocenić, jak daleko jest do pełnej wersji funkcji, więc na przykład, jeśli moja pierwsza użyteczna wersja jest ukończona w 33%, nadaję numer wersji 0.3.0 lub podobny. Następnie, w miarę zbliżania się do funkcji, uzupełnij odpowiednie wersje w podobny sposób.

Ale kiedy przejdziesz do przeszłości, pełna wersja funkcji musi się zmienić

Wybierając numery wersji dla npmpakietu, należy pamiętać, że w przypadku zależności wymienionych wpackage.json zakresach semver nie będzie działać poniżej wersji 1.0.0. To jest,

"dependencies": {
    "my-package": "^0.5"
}

jest równa

"dependencies": {
    "my-package": "0.5"
}

Jeśli chcesz mieć możliwość używania zakresów semver lub chcesz pozwolić innym osobom na ich używanie, możesz zacząć od wersji 1.0.0

Zazwyczaj wersjonowanie ma pewne znaczenie dla programisty. Zwiększenie liczby głównej może oznaczać duże zmiany, które uniemożliwiają zgodność z poprzednimi wersjami. Inne liczby w numerze wersji mogą wskazywać na mniejsze ulepszenia funkcji lub poprawki błędów.

Jeśli martwisz się, że wersja 0.6.5 ma niekompletny pierścień, możesz zechcieć promować ją pod wersją 1.0. Twój numer wersji marketingowej nie musi odpowiadać wewnętrznemu numerowi wersji. Na przykład numer wersji systemu Windows 7 to 6.1.

Osobiście wolę zacząć od wersji 0.1.0 i stamtąd.

Zależy od projektu. W przypadku prostych narzędzi wiersza poleceń zwykle zaczynam od około 0,9 [.0], ponieważ rozważam wypuszczenie lub spakowanie ich tylko wtedy, gdy są bliskie ukończenia (lub w każdym razie gotowe do testów beta). Bardziej skomplikowane projekty zaczynają się około 0,1 [.0] i niektórzy nawet nie widzą 1.0. Uważam wersję 1.0 za wydanie (lub przynajmniej lokalnie przetestowaną wersję beta lub kandydata do wydania) i odpowiednio planuję.

W przypadku projektów zespołowych, decyduje ten, kto umieści tag pierwszej wersji :).

0.1.0 jest tym, od czego zaczynam i przechodzę dalej. To właśnie dostosowałem do Xploration By Adrian, chociaż we wczesnych latach byłem bardzo sporadyczny i używałem 1.0.0, 0.0.1 i kilku innych. Ale polecam zacząć od 0.1.0 i stamtąd.

Per Semver, zarezerwuj a i c w abc dla A. Twoje pierwsze oficjalne wydanie i C. Poprawki błędów i łatki. Dzieje się tak, ponieważ wersja główna generalnie psuje starszy kod. A łatki po prostu naprawiają błędy. To wszystko zależy od osobistych preferencji, 0.99.0 nie oznacza, że ​​musisz przejść do 1.0.0, itd. Widziałem takie, które sięgają aż do 0.218.42.

Numery wersji powinny mieć dla ciebie znaczenie, jak poprawnie skomentowała wcześniej Arrieta .

Może po czymś takim jak: Pierwszy # to wydanie burmistrza, drugi # to to samo wydanie burmistrza z dodanymi niektórymi funkcjami, a trzeci # to to samo wydanie burmistrza, z tymi samymi funkcjami, ale z poprawionymi błędami lub dodanymi niewielkimi (ale wystarczająco znaczącymi) zmianami.

1.3.2 => Pierwsze wydanie, z większą liczbą funkcji i poprawionymi niektórymi błędami.

Jednak w przypadku użytkowników końcowych niektórzy są przyzwyczajeni do dużych liczb w przypadku ostatecznych wydań.

Na przykład: Corel 8, dla 8.0.0, 8.0.1, 8.2.2, itd. Corel 9, dla 9.0.0 ... itd.

A przede wszystkim dotyczy strategii marketingowych, takich jak: Corel X5 zamiast na przykład Corel 15.0.2.

Powiedziałbym, że zależy to od tego, czy numer wersji jest dla Ciebie, czy dla klienta.

zacznij od 0.0.0 i przejdź dalej.

Zacznij od wersji 1.1.1 i przejdź dalej.