There are still problems with completely reproducing old analyses partly due to our (current) inability to reproduce an exact version (as Martin says).
But I don't think we should muddle the waters and mix URL schemas with versioning. What Wolfgang is asking for is something I think makes total sense and which I support: the ability to refer to a single url and get the "latest" version of a package. The url I usually give out is ../release/PACKAGE.html but that does not work for a package which has not yet been part of a release. Depending on your manuscript / package development process I could easily see a manuscript getting accepted for publication around the same time the package gets accepted into Bioc. It has happened to me. And like Wolfgang, I don't like to have ../devel/PACKAGE.html links in my papers. To me, this seems like a very slight extension to the ../release/PACKAGE.html schema, and I don't really understand the reluctance to have this. I am also happy to start a discussion on how to refer to specific versions of a package including what we might need to support in Bioconductor to achieve better reproducibility - which is what I think Gabe refers to - but I don't think we should confuse this (important) issue with the schema request. Best, Kasper On Tue, Mar 24, 2015 at 11:15 AM, Gabe Becker <becker.g...@gene.com> wrote: > On Tue, Mar 24, 2015 at 7:28 AM, Wolfgang Huber <whu...@embl.de> wrote: > > > > 5. At the end of the day I find myself casting my lot for landing pages > > with the form > > > http://bioconductor.org/release/BiocGenerics/ > > > which leads to a little less typing but not the dynamic resolution that > > started this (version) of the thread. > > > > But we already have dynamic resolution. Even > > http://bioconductor.org/release/BiocGenerics will point to different > > package versions (e.g. after bugfixes) as time goes by. > > So the attribute “release” is dynamically resolved. > > All I am asking for is another attribute that means “the best that we > > currently have”, i.e. release if it exists and devel otherwise. > > > > I didn’t expect so much disagreement on so mundane an issue. And there > are > > plenty of ways of doing this outside the Bioc webpage, any of the public > > ’tiny URL’ services, through my own webpage, or by just telling people to > > google the package name. > > > > I just think there are a couple of subtleties here. I certainly don't > begrudge people wanting to type less and find packages easier. But if a > naive user with a default (read: release) Bioc installation goes to > http://bioconductor.org/CoolAwesomePkg and see's that it is "available in > bioconductor" but then can't install it because it is only in devel, are > they going to be less confused, or more? I don't know the answer to that, > but I think it's something to consider. > > Also, as I have said elsewhere, though I acknowledge that you seem to > disagree, I think such urls are substantially less appropriate for > credit/citation in publications. A link that brought users to the version > in question, but which - if not current - had a prominent link to the > current version would be better imho. > > > > > > > > On 24 Mar 2015, at 12:14, Martin Morgan <mtmor...@fredhutch.org> > wrote: > > > > > > 4. In terms of best practices, it seems like articles are about > > particular versions and should cite the package as such, for instance if > > only in devel when the paper is being written as .../3.1/..., but that > > there is no substantive cost to also referencing 'current version > available > > [after April, 2015] at .../release/…. > > > > I don’t agree. This would mean that for each later version of the same > > package, even just after a trivial typo fix, there is either no article, > or > > another one would have to be written. I don’t think this has an easily > > formalized solution, some good judgement is required. > > E.g. try to apply the above reasoning to > > > http://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1003118 > > > I agree that there can be a bit of a "beard problem*" here. If people > follow the Bioc development guidelines, though, I think a pretty good rule > of thumb can be had: bugfix version changes (in the major.minor-bugfix > nomenclature) are (relatively unambiguously) the "same" software from a > publication standpoint, while package versions with minor or major version > differences are not. This doesn't mean that a new article need to be > written, imo, just that awareness that the article discussed a different > version of the software - and that users should see the NEWS file or > current documentation for fully up-to-date information - is important. > > Not to harp on you personally, Wolfgang, because your paper with Simon > about DESeq was ahead of its time (and ours, sadly) on many of these > issues, but the API and default behavior of DESeq have changed > substantially (and for the better!) since its publication [1]. > > As a never-going-to-happen pipedream, this would be even more > straight-forward if Bioc package version numbers were of the form > (BiocVersion.PkgVersion-bugfix). Then the automatic incrementing of package > versions for bioc releases wouldn't muddy the waters here. > > > * The philosophical issue where some men obviously have beards, and some > men obviously don't, but there is no exact number of facial hairs at which > one unambiguously transitions from not having a beard to having one. > > [1] > > http://blog.revolutionanalytics.com/2014/08/gran-and-switchr-cant-send-you-back-in-time-but-they-can-send-r-sort-of.html > > ~G > -- > Gabriel Becker, Ph.D > Computational Biologist > Genentech Research > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
