[Biojava-dev] Please direct pull requests to the appropriate branch

[Spencer Bliven]

We knew there would be some overhead with switching to semantic versioning.
There is no way to avoid making decisions about which version a given
commit should be contribute to if we want to support simultaneous
development of multiple versions. With the 3-branch method we are just
paying that cost as we develop, rather than requiring someone to sort it
all out at release time. If this is really an unacceptable barriar to
contributions, then we could talk about switching to single-version
development (e.g. only releasing major releases). However, I strongly
suggest that we give the current system a few months to try it out before
changing it.

Andreas, master should remain as the 5.0.0 branch because it is much easier
to cherry-pick commits from master to the other branches than to get rid of
api-changing commits that get accidentally pushed to patch. As to "the
branch on which most developments happen", I would generally expect this
*not* to be the patch branch, as most interesting changes either add
features or break the API.

I agree that this needs to be better documented. I'll work on adding
something to the project README.

-Spencer

On Fri, Feb 20, 2015 at 10:10 AM, Jose Manuel Duarte <jose.duarte at psi.ch>
wrote:

>  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.
>
> 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.
>
> 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.
>
> 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.
>
> Jose
>
>
>
>
> On 19.02.2015 16:11, Andreas Prlic wrote:
>
> Hi Spencer,
>
>  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.
>
>  There are more than one way of dealing with branches. We need to agree
> on one strategy and document this well.
>
>  Andreas
>
>
>
> On Thu, Feb 19, 2015 at 2:09 AM, Spencer Bliven <sbliven at ucsd.edu> wrote:
>
>>   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).
>>
>>  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.
>>
>>  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.
>>
>>  Cheers,
>> Spencer
>>
>> _______________________________________________
>> biojava-dev mailing list
>> biojava-dev at mailman.open-bio.org
>> http://mailman.open-bio.org/mailman/listinfo/biojava-dev
>>
>
>
>
>
>
> _______________________________________________
> biojava-dev mailing listbiojava-dev at mailman.open-bio.orghttp://mailman.open-bio.org/mailman/listinfo/biojava-dev
>
>
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at mailman.open-bio.org
> http://mailman.open-bio.org/mailman/listinfo/biojava-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biojava-dev/attachments/20150220/19b49f75/attachment.html>