[Bioc-devel] push changes to devel

Kasper Daniel Hansen khansen at stat.berkeley.edu
Sun Jan 10 23:55:30 CET 2010


Thanks for the clarifications.  As is evident from my original email, this works a bit differently than I expected.

Leaving aside my current issues that are easily resolvable,  I would find it more natural that R CMD check on package A (which depends on package B) uses the version of package B obtainable by biocLite.  But if this is the first time this issue has appeared in the last many years, it is probably not worth spending any more time on.

Kasper


On Jan 8, 2010, at 19:28 PM, Seth Falcon wrote:

> 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
> 
> _______________________________________________
> Bioc-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



More information about the Bioc-devel mailing list