[Bioc-devel] Distinction between release and devel package websites

Dan Tenenbaum dtenenba at fhcrc.org
Thu Jul 24 23:04:42 CEST 2014



----- Original Message -----
> From: "Leonardo Collado Torres" <lcollado at jhu.edu>
> To: bioc-devel at r-project.org
> Sent: Wednesday, July 23, 2014 6:41:06 PM
> Subject: Re: [Bioc-devel] Distinction between release and devel package	websites
> 
> > Date: Wed, 23 Jul 2014 11:33:44 -0700
> > From: Martin Morgan <mtmorgan at fhcrc.org>
> > To: Matthew McCall <mccallm at gmail.com>, Michael Lawrence
> >         <lawrence.michael at gene.com>
> > Cc: "bioc-devel at r-project.org" <bioc-devel at r-project.org>
> > Subject: Re: [Bioc-devel] Distinction between release and devel
> >         package websites
> > Message-ID: <53D00008.1090100 at fhcrc.org>
> > Content-Type: text/plain; charset=windows-1252; format=flowed
> >
> > Dan has implemented these changes. Go to the Bioconductor home page
> > and in the
> > search box at the top right enter
> >
> >    supraHex
> >
> > (winner of the ISMB 2014 Best Artwork Award! Check out the URL on
> > the package
> > landing page). You'll see that the first link is to supraHex, and
> > the second to
> > supraHex (development version).
> >
> > On the supraHex (development version) page you'll see text
> > indicating that
> > you're looking at the development version, and for the release you
> > should go
> > somewhere else.
> >
> > Further down the installation instructions are now in their own
> > section, adding
> > a little more emphasis.
> >
> > The Documentation section includes instructions --
> > browseVignettes("supraHex")
> > -- for getting your version of the vignettes.
> >
> > The 'download' section is now called 'Package Archives'.
> >
> > The Package Archives section starts with a sentence pointing to
> > Installation
> > instructions.
> >
> > Mousing over one of the links pops up a tool tip encouraging you
> > once again to
> > use biocLite.
> >
> > Relevant changes also apply to release landing pages.
> >
> > As Vince mentioned, it is REALLY IMPORTANT that users do not mix
> > release and
> > devel versions of packages in a single library. Even if it 'works
> > for package
> > X', this invariably leads to incompatibilities and confusion. For
> > those users
> > wanting new features, tell them to switch to using the development
> > version,
> > e.g., as outlined at
> >
> >    http://bioconductor.org/packages/release/bioc/html/supraHex.html
> >
> > Thanks for your input,
> >
> > Martin
> >
> 
> Hi,
> 
> I just caught up to date with this conversation and I like the
> implemented changes. Great job! I hope that they will be effective.
> 
> Just some minor details:
> * Maybe the tooltip over the zip and tarball links when on a devel
> page can show a link to
> http://bioconductor.org/developers/how-to/useDevel/ Alternatively,
> the
> link could be under the "Package Archives" section by modifying
> "Follow Installation instructions to use this package in your R
> session." to something like "Follow Installation instructions to use
> this package in your R session. Verify that you are using the devel
> version."
> * I was looking forward to the svn links (for devel pages), are you
> still going to add them? If not, I understand that they are not
> necessary.


I just added this, a Browse/checkout source link in the package archives section.
This is for release packages as well as devel. There's no such link for annotation packages
because those don't live in svn..

Dan


> 
> Also, about svn, well.... I guess that I'm from the more recent group
> that knows git/Mercurial but never learned svn (hence why I haven't
> followed up on Hervé's suggestion in an earlier thread). I thought I
> wasn't going to need to (thanks to the Git-SVN bridge!), but well,
> seems like I'll at least need to learn some basic svn.
> 
> Finally, regarding the issue of pushing new features to devel
> versions
> (and not release), I understand the reasons for doing so. In my case,
> what I have been trying to do to minimize major differences between
> the versions is to keep working on the package outside of BioC until
> we are more confident on its stability. Kind of pre-devel. Pre-devel
> users (just a handful) can then install it via
> devtools::install_github(). I understand that not every package
> workflow is like this, but well, it could be a suggestion worth
> mentioning at
> http://www.bioconductor.org/developers/package-guidelines/
> Though of course, maybe it's better to have "pre-devel" packages be
> submitted to BioC-devel and drive all the traffic through BioC. Just
> some thoughts.
> 
> Cheers,
> Leo
> 
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 



More information about the Bioc-devel mailing list