|
From: Mojca M. <moj...@gm...> - 2017-10-18 05:56:53
|
17. okt. 2017 18:06 steam wrote: On Wednesday, 18 October 2017 02:12:51 Mojca Miklavec wrote: > 17. okt. 2017 09:01 "Eric S. Raymond" wrote: > I would suggest unifying those names (perhaps to something like v5.2.rc0), > but that can be done later. ??? Sorry, I don't get it. Why would you want to unify any of those? Why would you want version 3.7.1 to be called GNUPLOT_RELEASE_3_7_1 and version 5.2.1 to be called Release_5_2_1? Why not use something following the same pattern for both? Like a simple v3.7.1/v5.2.1? What I want is to be able to check them out separately. Sure, changing the name won't disable it, but unless you unify names, you'll have to check the exact name for each revision you'll want to checkout. Everything labeled pre* or BETA* can be junked, but that is not what I understand as "unify". Now maybe I just misunderstand the whole git thing. Remember I'm new to this and thinking in terms of CVS. What I'm thinking is that if I do git checkout Release_5_0_7 I'll get the same files that were in the release tarball gnuplot-5.0.7.tar.gz No, you won't because the generated files (configure etc) are missing. On Github one can attach files to tags though. And if for some reason we wanted to continue development of the 5.0 series for a release 5.0.8, I could clone it (I don't know what git command that is) as a new branch Release_5_0_8 and push that one back to the repository. Have I got that wrong? You would checkout the branch 5.0, make changes to it and then tag a new release. You would never make a 5.0.8 branch, only a tag. Mojca |