<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    This is indeed a difficult issue. I think that in principle it is a
    good idea to keep the separate branches and have a cleaner
    developing progress. Thus I supported Spencer's idea of splitting
    into patch/minor/master. <br>
    <br>
    At the same time this system adds to the complexity of the workflow
    and especially makes things more complicated for newcomers and that
    is an important concern. Also things are less agile: it forces to
    think in a rather rigid development scheme that can make things
    slower, departing from the release-fast philosophy.<br>
    <br>
    With the little experience we've had so far we have already seen
    issues with it, e.g. there was a pull request merged to master that
    should have gone to patch. I can see this kind of things happening
    often. Pull requests from new contributors will surely be going to
    master if they don't know our policies. For some people git is
    complex enough and adding the several branches layer makes things
    even more difficult.<br>
    <br>
    So if we need to rethink this I would support the simple approach of
    a monolithic master-only development. In a world of a few core
    developers only, the multi-branch option would be fine. For a more
    realistic scenario with an open community with new contributors
    coming in all the time, simple sounds like the best idea.<br>
    <br>
    Jose<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 19.02.2015 16:11, Andreas Prlic
      wrote:<br>
    </div>
    <blockquote
cite="mid:CALthepwm1Qy2v3QUWaSpTcZ_V9wFL78z3GXj73nTNeYOSrvRFw@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div dir="ltr">Hi Spencer,
        <div><br>
        </div>
        <div>By having the master branch flagged for a future 5.0
          release, I am concerned that we are making contributions more
          difficult. Shouldn't master be the main branch on which most
          developments happen? Our goal is to enable the ease of
          contribution and to make frequent releases. </div>
        <div><br>
        </div>
        <div>
          <div>There are more than one way of dealing with branches. We
            need to agree on one strategy and document this well.</div>
        </div>
        <div><br>
        </div>
        <div>Andreas</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, Feb 19, 2015 at 2:09 AM,
            Spencer Bliven <span dir="ltr">&lt;<a
                moz-do-not-send="true" href="mailto:sbliven@ucsd.edu"
                target="_blank">sbliven@ucsd.edu</a>&gt;</span> wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div dir="ltr">
                <div>
                  <div>
                    <div>As a reminder to everyone, we're currently
                      maintaining separate branches for patch, minor,
                      and master which correspond to features for 4.0.1,
                      4.1.0, and 5.0.0 respectively. One thing that
                      would really help with this is if everyone can
                      make pull requests to the correct branch, rather
                      than accepting the default of master. This can be
                      done from the compare screen by selecting the
                      appropriate base branch (on the left).<br>
                      <br>
                    </div>
                    I also recommend maintaining local
                    patch/minor/master branches, to allow testing with
                    the correct features. I know this is a bit of a
                    hassle, but let's at least give it a shot.<br>
                    <br>
                  </div>
                  It is important to never merge master into either of
                  the earlier branches. If features from master need to
                  be back-ported to patch or minor, this can be done
                  with git's cherry-pick command.<br>
                  <br>
                </div>
                Cheers,<br>
                Spencer<br>
              </div>
              <br>
              _______________________________________________<br>
              biojava-dev mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:biojava-dev@mailman.open-bio.org">biojava-dev@mailman.open-bio.org</a><br>
              <a moz-do-not-send="true"
                href="http://mailman.open-bio.org/mailman/listinfo/biojava-dev"
                target="_blank">http://mailman.open-bio.org/mailman/listinfo/biojava-dev</a><br>
            </blockquote>
          </div>
          <br>
          <br clear="all">
          <div><br>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
biojava-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:biojava-dev@mailman.open-bio.org">biojava-dev@mailman.open-bio.org</a>
<a class="moz-txt-link-freetext" href="http://mailman.open-bio.org/mailman/listinfo/biojava-dev">http://mailman.open-bio.org/mailman/listinfo/biojava-dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>