[Bioc-devel] Short URLs for packages?
Kasper Daniel Hansen
kasperdanielhansen at gmail.com
Tue Mar 24 16:46:46 CET 2015
There are still problems with completely reproducing old analyses partly
due to our (current) inability to reproduce an exact version (as Martin
But I don't think we should muddle the waters and mix URL schemas with
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
On Tue, Mar 24, 2015 at 11:15 AM, Gabe Becker <becker.gabe at gene.com> wrote:
> On Tue, Mar 24, 2015 at 7:28 AM, Wolfgang Huber <whuber at 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
> > 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 <mtmorgan at fredhutch.org>
> > >
> > > 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
> > [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,
> > 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
> 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 .
> 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.
> Gabriel Becker, Ph.D
> Computational Biologist
> Genentech Research
> [[alternative HTML version deleted]]
> Bioc-devel at r-project.org mailing list
[[alternative HTML version deleted]]
More information about the Bioc-devel