Skip to content

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

4 messages · Martin Morgan, Leonardo Collado Torres

#
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
#
On 07/23/2014 06:41 PM, Leonardo Collado Torres wrote:
Frankly, this doesn't sound like a good idea to me. It confuses the user (what, 
I'm supposed to be using github? I thought this was a Bioconductor package!), 
makes your life as a developer difficult (three versions to maintain), and 
introduces code (i.e., bugs!) where it isn't tested.

I'd just go for broke, make wild changes to your devel code, let the build 
system do it's magic, get leading-edge users to knowingly try out your changes, 
shake out some bugs, and have a nice clean ride into release and a grateful 
audience of appreciative users. Sure work in git if that's your flavor, but 
merge frequently with master and sync with bioc; never expect your users to 
install 'the latest' from github.

Martin
#
On Thu, Jul 24, 2014 at 12:17 AM, Martin Morgan <mtmorgan at fhcrc.org> wrote:
I agree with what you said. I was just talking about the development
stage before you submit the package the first time to BioC. After it's
in BioC then yes, don't ask users to install from GitHub. And well, as
I understand it, the Git-SVN bridge makes it easy to push to
Bioc-devel and Bioc-release (following the suggestion posted here
https://www.mail-archive.com/bioc-devel at r-project.org/msg01967.html).

Or what system do you suggest using for that first development cycle
before submitting to BioC?

Our way of hosting the pre-devel version on GitHub without any
publicity and iterating there until we feel the package is mature for
BioC seems to be working for us. But well, it might be slow and we
could be losing out a lot by not having it in Bioc-devel. On the other
hand, we wanted to avoid confusing users with major changes to the
package. In the end, I'm torn between the "you only make a first
impression once, so make it good" approach vs "get it out there, then
fix it" approach.

In the end, I'm a newbie at developing packages and I'm still learning ^^'
1 day later
#
On 07/23/2014 09:59 PM, Leonardo Collado Torres wrote:
>>> Finally, regarding the issue of pushing new features to devel versions
 >>> (and not release), I understand the reasons for doing so. In my case,

;)
There are so many ways in which code ends up as a bioc package that I don't 
think I have anything useful to say here.

and...
these shouldn't be mutually exclusive; aim for a well-defined problem and write 
effective code for it. Things go wrong for me when I try to be too ambitious, 
take short cuts hoping to make fast progress, or make public code that I was 
really still just thinking through.

Martin