[Bioc-devel] Best practice on commit

Hi Nicolas,

after doing a bit of work on the BridgeDbR package this weekend, I was
wondering exactly the same thing. I prefer small patches, so that I can
easily link the change with the commit message and have related changes
together (and fairly, it allows me to see when I actually work on what
(#academicTimeReporting)... But previously I learned that when you push
something to the repository, you should bump the question, so currently I
do this for every change I made, leaving a ridiculous number of minor
release and really short NEWS entries...

Working in a branch and when only bumping the version number just before
the merge into master makes a lot of sense to me.

Can some senior developer and/or gatekeeper confirm that that is acceptable
commit practice?

Egon



On Fri, Feb 23, 2018 at 8:24 PM, Nicolas Descostes <
nicolas.descostes at gmail.com> wrote:

 Dear Bioconductor community,

When developing further a package, is the best practice to create a

branch

and bump the version when a full new feature is merged or to stay on the
master without bumping when committing temporarily? More generally, When

do

you usually bump a version?

Thank you.

Nicolas

        [[alternative HTML version deleted]]

--
E.L. Willighagen
Department of Bioinformatics - BiGCaT
Maastricht University (http://www.bigcat.unimaas.nl/)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: https://www.zotero.org/egonw
ORCID: 0000-0001-7542-0286 <http://orcid.org/0000-0001-7542-0286>
ImpactStory: https://impactstory.org/u/egonwillighagen

        [[alternative HTML version deleted]]

This was recently discussed:

https://stat.ethz.ch/pipermail/bioc-devel/2018-February/012875.html

On Sun, Mar 11, 2018 at 4:10 AM, Egon Willighagen <
egon.willighagen at gmail.com> wrote:

Hi Nicolas,

after doing a bit of work on the BridgeDbR package this weekend, I was
wondering exactly the same thing. I prefer small patches, so that I can
easily link the change with the commit message and have related changes
together (and fairly, it allows me to see when I actually work on what
(#academicTimeReporting)... But previously I learned that when you push
something to the repository, you should bump the question, so currently I
do this for every change I made, leaving a ridiculous number of minor
release and really short NEWS entries...

Working in a branch and when only bumping the version number just before
the merge into master makes a lot of sense to me.

Can some senior developer and/or gatekeeper confirm that that is
acceptable
commit practice?

Egon



On Fri, Feb 23, 2018 at 8:24 PM, Nicolas Descostes <
nicolas.descostes at gmail.com> wrote:

 Dear Bioconductor community,

When developing further a package, is the best practice to create a

branch

and bump the version when a full new feature is merged or to stay on the
master without bumping when committing temporarily? More generally,

When do

you usually bump a version?

Thank you.

Nicolas

        [[alternative HTML version deleted]]

--
E.L. Willighagen
Department of Bioinformatics - BiGCaT
Maastricht University (http://www.bigcat.unimaas.nl/)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: https://www.zotero.org/egonw
ORCID: 0000-0001-7542-0286 <http://orcid.org/0000-0001-7542-0286>
ImpactStory: https://impactstory.org/u/egonwillighagen

        [[alternative HTML version deleted]]

--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
<https://maps.google.com/?q=4225+Roosevelt+Way+NE,+%23+100+Seattle+WA+98105&entry=gmail&source=g>
Seattle WA 98105
<https://maps.google.com/?q=4225+Roosevelt+Way+NE,+%23+100+Seattle+WA+98105&entry=gmail&source=g>-6099

But previously I learned that when you push
something to the repository, you should bump the question, so currently I
do this for every change I made, leaving a ridiculous number of minor
release and really short NEWS entries...

On Sun, Mar 11, 2018, at 4:10 AM, Egon Willighagen wrote:

But previously I learned that when you push
something to the repository, you should bump the question, so currently I
do this for every change I made, leaving a ridiculous number of minor
release and really short NEWS entries...

I wondered about this, particularly for the NEWS entries. What I have been doing is bumping the version number for each commit - to make sure that the checks on the server get run - but collapsing multiple version bullets into a single NEWS item. i.e., my NEWS looks like:

++++
Changes in version 1.5.6 (2018-03-08)
-------------------------------------

User Visible Changes:

     * BUG FIX: the G2 peak of the B sample was not getting incorporated
       into model construction, which caused model fitting to fail on
       samples with histograms skewed towards the left.

     * Updated DebrisModel documentation.

Internal Changes:

     * Fixed broken test.

Changes in version 1.5.3 (2018-01-17)
-------------------------------------

++++

I think that will be more convenient for users, who won't care that the bug fix, updated documentation, and fixed test were actually three different commits. If they do want that level of detail, that information is available directly from the repository. And from my perspective, I definitely wanted to bump the version for at least the test fix and the bug fix, to make sure that the server-side tests were run.

Best,

Tyler

Just to clarify, all software packages are built and checked every
night, independently of whether their version got bumped or not.
The version bump only allows the modified package to propagate
to the public repo and become available via biocLite(), possibly
replacing the previous version of the package (if one is already
available).

The package landing page on the website should reflect what's in
the public repo for a given BioC version at any time (the landing
pages can lag behind by about 20 min which is the time it takes
to regenerate all the package landing pages after the daily package
propagation).