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

Fri Feb 20 23:38:20 UTC 2015

I'd argue that most patches and commits don't change the API. As such I'd
keep the master branch version number set to the next minor release version
(the way it always was). If somebody does a major change that breaks
backwards compatibility, that's A) a rare thing and B) usually done from
one of the senior contributors, who know about our branching and release
strategy.  Such changes would get pushed to the corresponding release
branch.

Since we are trying to keep up frequent releases it also means that the
branch with the API change would get published soon after. This means that
this would not be much different from a single-version-development.

A

On Fri, Feb 20, 2015 at 5:43 AM, Spencer Bliven <sbliven at ucsd.edu> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/8ba49946/attachment-0001.html>