It seems that the short URLs on devel landing pages refer to release pages. Intended?
On Wed, Jul 8, 2015 at 2:19 PM, Dan Tenenbaum <dtene...@fredhutch.org> wrote: > > > ----- Original Message ----- > > From: "Vincent Carey" <st...@channing.harvard.edu> > > To: "Dan Tenenbaum" <dtene...@fredhutch.org> > > Cc: "Tim Triche, Jr." <ttri...@usc.edu>, bioc-devel@r-project.org, > "Gabe Becker" <becker.g...@gene.com>, "Martin > > Morgan" <mtmor...@fredhutch.org> > > Sent: Tuesday, July 7, 2015 1:12:26 PM > > Subject: Re: [Bioc-devel] Short URLs for packages? > > > > > > OK, thanks. Should we add a little bit to each package landing page > > indicating how to link? > > > > > > Done. For example go to > http://bioconductor.org/packages/release/bioc/html/a4.html and scroll to > the bottom, the short url appears just before "Package Download Stats". > > Dan > > > > On Tue, Jul 7, 2015 at 3:52 PM, Dan Tenenbaum < > > dtene...@fredhutch.org > wrote: > > > > > > > > > > ----- Original Message ----- > > > From: "Vincent Carey" < st...@channing.harvard.edu > > > > To: "Martin Morgan" < mtmor...@fredhutch.org > > > > Cc: "Tim Triche, Jr." < ttri...@usc.edu >, bioc-devel@r-project.org > > > , "Gabe Becker" < becker.g...@gene.com > > > > Sent: Tuesday, July 7, 2015 12:49:24 PM > > > Subject: Re: [Bioc-devel] Short URLs for packages? > > > > > > Has there been a solution to the short URL question? > > > > > > > Yes: https://stat.ethz.ch/pipermail/bioc-devel/2015-April/007464.html > > > > Dan > > > > > > > > > > > On Tue, Mar 24, 2015 at 7:14 AM, Martin Morgan > > > < mtmor...@fredhutch.org > > > > wrote: > > > > > > > On 03/24/2015 02:31 AM, Wolfgang Huber wrote: > > > > > > > >> Before we start a religious war, can we make progress on the > > > >> pragmatic > > > >> goal of making it possible to provide such URLs to people? > > > >> > > > >> There are two concepts > > > >> - ‘the package' - a specific version, running in a specific > > > >> environment, > > > >> ‘frozen’, etc. (Gabe) > > > >> - ‘the package’ - as a concept and a living artifact (me, Bernd, > > > >> Tim) > > > >> Both are useful. And having URLs for both would also be useful. > > > >> > > > > > > > > 0. That's (mostly) satisfied with the current scheme and > > > > > > > > http://bioconductor.org/packages/3.0/bioc/html/BiocGenerics.html > > > > http://bioconductor.org/packages/release/bioc/html/BiocGenerics.html > > > > http://bioconductor.org/packages/devel/bioc/html/BiocGenerics.html > > > > > > > > (hey, no www. -- that's four letters already! Perhaps > > > > importantly, > > > > there's > > > > also a hard-coded version for devel, 3.1, and for past releases. > > > > So > > > > as I > > > > understand it the request is for (a) shorter path names and (b) > > > > dynamic > > > > selection of release vs. devel, mentioned below, for the <6 month > > > > period > > > > when the package is in devel but not yet release. Also noted is > > > > Henrik's > > > > earlier proposal mentioned by Sean. > > > > > > > > > > > > 1. 'packages', 'bioc', 'html' all look somehow redundant, so > > > > > > > > http://bioconductor.org/release/BiocGenerics.html > > > > http://bioconductor.org/devel/BiocGenerics.html > > > > http://bioconductor.org/3.0/BiocGenerics.html > > > > > > > > but also > > > > > > > > http://bioconductor.org/release/BiocGenerics/ (implicit > > > > index.html) > > > > http://bioconductor.org/BiocGenerics/release/ > > > > > > > > and their devel and version counterparts would seem quite > > > > possible > > > > / not > > > > profoundly controversial. Landing pages for specific versions > > > > 3.22.7 do > > > > not currently exist, change little across package minor versions, > > > > and would > > > > not lead to packages installable via biocLite(), so this idea of > > > > Tim's is a > > > > non-starter in my opinion. > > > > > > > > Having the 'version' level of the path before the package > > > > provides > > > > a > > > > logical place to put biocViews for that release. I'd vote for one > > > > of the > > > > release/BiocGenerics[.html] schemes. > > > > > > > > > > > > 2. Something like > > > > > > > > http://bioconductor.org/BiocGenerics > > > > > > > > redirecting to release when available, devel when newly added > > > > (Wolfgang's > > > > proposal) would in my opinion be confusing, especially since we > > > > continue to > > > > have so much difficulty with version mismatches in user > > > > installations. I > > > > don't think having a warning on redirect that 'this package is > > > > not > > > > available for release' would be effective either at advertising > > > > robust > > > > software or at enabling use by comparatively naive users. > > > > > > > > > > > > 3. In terms of the 'redundant' parts of the path, these are not > > > > completely > > > > arbitrary (not that these considerations have to dictate > > > > presentation; they > > > > do make one suspect that 'add a redirect and everything will be > > > > fine' will > > > > result in a nice plate of spaghetti, especially if there is some > > > > desire to > > > > retain backward compatibility). > > > > > > > > 'packages' separates the package repository from other aspects of > > > > bioconductor.org , and group related concepts ('package', 'help', > > > > etc.) at > > > > a similar hierarchical level. > > > > > > > > 'bioc' serves to distinguish between software ('bioc/'), > > > > annotation > > > > ('data/annotation') and experiment data ('data/experiment') > > > > packages, and > > > > these divide the overall repository into three for the purposes > > > > of > > > > biocLite() / install.packages() (this conceptual distinction has > > > > been > > > > useful, I think). > > > > > > > > > biocinstallRepos() > > > > BioCsoft > > > > " http://bioconductor.org/packages/3.1/bioc " > > > > BioCann > > > > " http://bioconductor.org/packages/3.1/data/annotation " > > > > BioCexp > > > > " http://bioconductor.org/packages/3.1/data/experiment " > > > > > > > > 'html' distinguishes the landing pages from the package tar balls > > > > / > > > > binary > > > > distributions themselves as returned by > > > > contrib.url(biocinstallRepos()), > > > > and from their vignette/, man/ and news/ resources. > > > > > > > > > > > > 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/.... > > > > > > > > > > > > 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. > > > > > > > > > > > > Martin > > > > > > > > > > > > > > > >> Wolfgang > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> On Mar 23, 2015, at 18:43 GMT+1, Tim Triche, Jr. > > > >> < tim.tri...@gmail.com > > > > >>> wrote: > > > >>> > > > >>> I just meant that the mnemonic link > > > >>> > > > >>> http://www.bioconductor.org/limma/ (SEO version of limma ;-)) > > > >>> > > > >>> could dump people at something like > > > >>> > > > >>> http://www.bioconductor.org/release/limma/3.22.7/ (I'd prefer > > > >>> this) > > > >>> > > > >>> or if need be for backwards compatibility, > > > >>> > > > >>> http://www.bioconductor.org/packages/3.0/limma/3.22.7/ (seems > > > >>> less > > > >>> good) > > > >>> > > > >>> instead of > > > >>> > > > >>> http://www.bioconductor.org/packages/3.0/bioc/html/limma.html > > > >>> (current) > > > >>> > > > >>> and furthermore the specific version page could note more > > > >>> prominently > > > >>> that > > > >>> the build of limma being referenced at that particular instance > > > >>> in time > > > >>> may > > > >>> or may not be the same as was cited in a paper, used in an > > > >>> analysis, > > > >>> available for download the previous evening, etc. thus > > > >>> citation("limma") > > > >>> is > > > >>> a Very Good Idea when writing up results that depend upon it. > > > >>> Because > > > >>> even > > > >>> the WEHI guys could theoretically have a bug that impacted > > > >>> someone's > > > >>> results (as opposed to the usual case of Didn't Read The Fine > > > >>> Limma > > > >>> Manual) > > > >>> > > > >>> Does that make more sense? (Probably not, but worth a try) > > > >>> > > > >>> Statistics is the grammar of science. > > > >>> Karl Pearson > > > >>> < http://en.wikipedia.org/wiki/The_Grammar_of_Science > > > > >>> > > > >>> On Mon, Mar 23, 2015 at 9:29 AM, Dan Tenenbaum > > > >>> < dtene...@fredhutch.org > > > > >>> wrote: > > > >>> > > > >>> > > > >>>> > > > >>>> On March 23, 2015 9:18:57 AM PDT, "Tim Triche, Jr." < > > > >>>> tim.tri...@gmail.com > > > > >>>> wrote: > > > >>>> > > > >>>>> > > > >>>>> Packages are (read: should be, IMHO) published, citable > > > >>>>> pieces > > > >>>>> of > > > >>>>>> > > > >>>>> research, though. Imagine if a paper you cite were silently > > > >>>>> updated > > > >>>>> without the doi/citation changing. That wouldn't be good > > > >>>>> > > > >>>>> I don't disagree, but the existing setup does nothing to > > > >>>>> address that. > > > >>>>> Citation('limma'), for example, does. > > > >>>>> > > > >>>>> .../release/... and .../devel/... can change at any time, > > > >>>>> potentially > > > >>>>> overnight (with or without a new BioC release). The only real > > > >>>>> way to > > > >>>>> cite an exact version is to cite that exact version, which is > > > >>>>> already > > > >>>>> the proper way to do things and would remain unaffected by > > > >>>>> this, at > > > >>>>> least AFAIK. > > > >>>>> > > > >>>>> Perhaps a useful addendum would be for the mnemonic > > > >>>>> > > > >>>>> http://bioconductor.org/limma > > > >>>>> > > > >>>>> To redirect to > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>> > http://bioconductor.org/packages/limma/whateverTheMostRecentStableVersionMayBe/ > > > >>>> > > > >>>>> > > > >>>>> And then everything is explicit. > > > >>>>> > > > >>>>> Does that address the competing issues discussed herein? > > > >>>>> > > > >>>> > > > >>>> > > > >>>> Note that 'release' and 'devel' are just symlinks to the > > > >>>> current > > > >>>> release > > > >>>> and devel versions. I.e. currently 3.0 and 3.1 respectively. > > > >>>> So > > > >>>> you can > > > >>>> always link directly to a specific version. > > > >>>> > > > >>>> Dan > > > >>>> > > > >>>> > > > >>>>> Best, > > > >>>>> > > > >>>>> --t > > > >>>>> _______________________________________________ > > > >>>>> 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 > > > >>> > > > >> > > > >> _______________________________________________ > > > >> Bioc-devel@r-project.org mailing list > > > >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > >> > > > >> > > > > > > > > -- > > > > Computational Biology / Fred Hutchinson Cancer Research Center > > > > 1100 Fairview Ave. N. > > > > PO Box 19024 Seattle, WA 98109 > > > > > > > > Location: Arnold Building M1 B861 > > > > Phone: (206) 667-2793 > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
