<div dir="ltr"><div dir="ltr"><div><br></div>My responses follow Kevin's questions/comments. <div><br></div><div><div><div><br clear="all"><div><div dir="ltr" class="m_-5878271033602014389gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Tim Hoar<div>Data Assimilation Research Section</div><div>National Center for Atmospheric Research</div><div><a href="mailto:thoar@ucar.edu" target="_blank">thoar@ucar.edu</a></div><div>303.497.1708</div></div></div></div></div></div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 4, 2019 at 9:30 AM Kevin Raeder <<a href="mailto:raeder@ucar.edu" target="_blank">raeder@ucar.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Tim,<br>thanks for organizing names at this opportune moment.<br>Here are my questions and thoughts.<br><br>For the big picture, are we moving away from the strategy of<br>"release after major improvements and name it after an island"?<br>Is the alternative to just tag a version of the public git(hub)<br>master, after it has passed all the tests?<br>The naming strategy for the future could or should determine<br>the renaming strategy for the old stuff.<br></div></blockquote><div><br></div><div>As per the release strategy,  naming things after islands and then re-releasing things with the same name can create confusion. Most everything uses 'semantic versioning', which I describe at the end of the following document: <a href="https://docs.google.com/document/d/1SFBt7YT0yZ7o2BD4_3CEhKNK_ZfGDCrhR9gr-EoAFcM/edit" target="_blank">https://docs.google.com/document/d/1SFBt7YT0yZ7o2BD4_3CEhKNK_ZfGDCrhR9gr-EoAFcM/edit</a>   'DART_conversion_process'      I'm proposing a    V x.y.z  approach, and have a table that converts our svn releases to the  semantic versions. </div><div><br></div><div>The timing and motivation of when to create a release stays the same. Yes, tagging a version of the public version is a 'release'. Whether we name it after an island or use semantic versioning - or do something like what apple does ('Mohave' is  OSX 10.14.5)  was something I was going to discuss next week or so. I view that as a separate issue from what we name our branches.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Are we abandoning the "trunk" terminology in favor of "master",<br>even though we're keeping git's "branches"?<br></div></blockquote><div><br></div><div>That is my porposal. Considering we have not been using 'trunk' for several years now, and had to rename our primary branch as 'rma_trunk', it seems to me that 'rma_trunk' fulfills the git role usually filled by 'master'.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I'm not such a fan of "classic" because it implies to me<br>some sort of standard, tried-and-true, always ready version,<br>while this version is more like "the old version you might<br>want to use if we didn't upgrade the part that you want."<br>My alternative would depend on whether we continue to use islands.<br></div></blockquote><div><br></div><div>No help.  I actually thought about starting these with 'zzz_'  so they would appear as the last set of branches when people listed the branches or used the pull-down menu of branches  on GitHub.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dropping 'rma_' sounds good.  Whether it is replaced by something<br>to denote Manhattan (or later release or tag names) depends on <br>our development strategy for the future.<br>Generally it's nice to have branch names<br>that communicate what's in them; the original version,<br>the major modification or project, etc., but it takes<br>some discipline to merge a branch back into the trunk<br>before its name becomes outdated.<br><br><div>If rma_trunk is the thing that was released as Manhattan,</div><div>then I'm fine with "The svn 'rma_trunk' branch will be named 'master'".</div></div></blockquote><div><br></div><div>Exactly. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'm very tripped up by<br>"(the traditional name for git development branches)"<br>My understanding of master is that it is the base<br>from which development branches are made.  It is not<br>modified until all the development work is done<br>and merged into the master.</div></div></blockquote><div><br></div><div>What I was trying to convey is that 'master' is to git what 'trunk' is to svn.  Subsequent branches are generally made from 'master', and get reintegrated into master. I did not mean to imply that master should be for development, but do mean that master is the 'bleeding edge' in that it is generally newer than what is released. Sorry for any confusion.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Kevin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 3, 2019 at 5:31 PM Tim Hoar <<a href="mailto:thoar@ucar.edu" target="_blank">thoar@ucar.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I am in the process of converting the svn DART repository to a git repository that will be available on GitHub.<div>There will be a private GitHub repository for development of branches that have private svn repositories.</div><div>After I verify the private GitHub repo is working correctly and has all the desired content, we will create another</div><div>public GitHub repo with just the public branches.<br><div><br></div><div>This seems like the right time to make some choices.</div><div><br></div><div>Since a git repo traditionally has all the branches available, I was wondering it it might be appropriate to adopt some</div><div>sort of convention about branch names.   Should all the branches based on the 'pre-Manhattan' file layout start with a 'classic_'  prefix?</div><div>It would be easy to document that any 'classic_' branch is in maintenance mode and will not get any more development.</div><div><br></div><div>There are a slew of branches that use the Manhattan layout ... most of them start with 'rma_'  which means little to</div><div>most people. Compound that with the fact that there are some 'rma_' branches that use the 'classic' file layout, and you see how</div><div>things can get misleading.</div><div><br></div><div>I propose that all the branches with the 'classic' layout get a 'classic' prefix, and any branch that uses the Manhattan layout simply use</div><div>the branch name ... and we drop the 'rma_' from the branch name if necessary.</div><div><br></div><div>The svn 'trunk' branch will be renamed  'classic'</div><div>The svn 'rma_trunk' branch will be named 'master'  (the traditional name for git development branches)</div><div><br></div><div>Please weigh in with your preferences/opinions as soon as possible. </div><div>Any and all advice is appreciated.</div><div><br></div><div>Thanks -- Tim </div><div><br></div><div>P.S. Also please be aware that the svn repository has been made readonly. We have a working git repository, but I want to</div><div>make the branch name changes (if necessary) as soon as possible and then I will push to GitHub.</div><div><br></div><div>Sincerely,  Tim - on behalf of the DART team.</div><div><br></div><div><div><div dir="ltr" class="gmail-m_-5878271033602014389gmail-m_2100965855764047686gmail-m_9075594253017110111gmail_signature"><div dir="ltr"><div><div dir="ltr">Tim Hoar<div>Data Assimilation Research Section</div><div>National Center for Atmospheric Research</div><div><a href="mailto:thoar@ucar.edu" target="_blank">thoar@ucar.edu</a></div><div>303.497.1708</div></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div>
</div>