[Bioc-devel] push changes to devel

[Seth Falcon]

On 1/8/10 9:07 AM, Kasper Daniel Hansen wrote:
> Recently GenomeGraphs had an update (in devel) where an argument name
> of makeBaseTrack changed from segmentation to trackOverlay.  This
> update happened without bumping the version number (and it happened
> before Xmas).
>
> When I install GenomeGraphs using biocLite on R-devel (using pkgType
> = "source") I get the old version of GenomeGraphs containing the
> argument name segmentation.  But on the other hand it is clear from
> the current build failure of Genominator that the version of
> GenomeGraphs used for R CMD check is the new version with the
> argument name trackOverlay.

As I understand it, the nightly build tests the latest svn version of 
all packages.

Only those packages that pass check with no error *and* have a version 
bump are pushed to the devel repos (hit by biocLite).

> I am now caught in a peculiar situation.  If I don't do anything,
> Genominator fails R CMD check.  But if I fix Genominator to use the
> new version of GenomeGraphs, it will pass R CMD check, but any user
> who downloads Genominator and GenomeGraphs through biocLite will find
> that they don't match up (because they will get the old version of
> GenomeGraphs).
>
> I could have made a mistake somewhere, but I have tried double
> checking it.
>
> For release I know that if a package gets updated, it needs to have
> its version bumped in order to be re-build.
>
> But for devel I assumed that as soon as I change something in svn,
> the changes are reflected in what is available through biocLite (of
> course, allowing for the package to be rebuild), no matter if I bump
> the version or not.  That does not seem to be the case.  And no
> matter what the rule is, it is confusing that a different version is
> used for R CMD check than what is available through biocLite.

I appreciate the confusion.  The current rule avoids having our 
repository (release or devel) serving the same version of a package with 
different underlying code and I think that's desirable.

> So essentially: what is the rules for version bumping in devel.

Version numbers are cheap and so as a rule, folks should be incrementing 
z in x.y.z for nearly all devel changes.  This is especially the case if 
changes are made that impact packages that depend on you.

> Also, it might make sense to write them down somewhere on the
> developer pages (where there might be some info, I just could not
> find it).

I think I hear a volunteer for adding something to the dev wiki ;-)

I suspect that this particular problem can be easily solved with a mail 
to the maintainer of GenomeGraphs.  If not, let us know.

Best Wishes,

+ seth

-- 
Seth Falcon
Bioconductor Core Team | FHCRC