[Bioc-devel] Short URLs for packages?

[Gabe Becker]

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 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 <mtmorgan at 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]]