[Bioc-devel] Short URLs for packages?

[Kasper Daniel Hansen]

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

	[[alternative HTML version deleted]]