> Date: Wed, 23 Jul 2014 11:33:44 -0700
> From: Martin Morgan <mtmor...@fhcrc.org>
> To: Matthew McCall <mcca...@gmail.com>, Michael Lawrence
> <lawrence.mich...@gene.com>
> Cc: "bioc-devel@r-project.org" <bioc-devel@r-project.org>
> Subject: Re: [Bioc-devel] Distinction between release and devel
> package websites
> Message-ID: <53d00008.1090...@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.
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
