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

[Martin Morgan]

On 07/23/2014 09:59 PM, Leonardo Collado Torres wrote:
> On Thu, Jul 24, 2014 at 12:17 AM, Martin Morgan <mtmorgan at fhcrc.org> wrote:
>> On 07/23/2014 06:41 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,
>>> 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 athttp://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.
>>
>>
>> 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.
>
> 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

 >>> Finally, regarding the issue of pushing new features to devel versions
 >>> (and not release), I understand the reasons for doing so. In my case,

;)

> 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@r-project.org/msg01967.html).
>
> Or what system do you suggest using for that first development cycle
> before submitting to BioC?

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...

>
> 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.

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

>
> In the end, I'm a newbie at developing packages and I'm still learning ^^'
>
>
>>
>> Martin
>> --
>> 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


-- 
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