[Phylobase-devl] release date

[Brian O'Meara]

I just wanted to pop up to add emphasis to François' suggestion about  
standardizing variable names and doing this and other variable or  
function name changes before a CRAN release (or even another R-SIG  
post). People will understand having limited functionality in an  
initial release, having to rely on Ape for some things, perhaps even  
some bugs, but they'll quickly lose confidence in using phylobase as a  
base package if they have to keep updating their code to track changes  
in the API in subsequent releases (think of the annoyance with the ape  
phylo change). [I haven't wanted to join the discussion over release  
dates and the like as I haven't contributed much coding lately and so  
shouldn't have much of a vote, but I thought that the importance of a  
stable API was worth stressing].

Congrats on the progress so far.

Brian



On Aug 27, 2009, at 7:42 PM, Peter D. Cowan wrote:

> On Thu, Aug 27, 2009 at 09:37:09AM -0700, Jim Regetz wrote:
>> I agree the recent progress has been great! I also agree with Peter's
>> sentiment, and am partial to François' second alternative: holding  
>> off a
>> little longer on the CRAN release to address these issues and others
>> that arise as we're working (we don't seem to have reached an  
>> asymptote
>> yet), but making an immediate announcement on R-sig-phylo to draw  
>> more
>> attention to the package on R-Forge. This should expand the user (and
>> thus tester) base, while still limiting it to folks who can be  
>> expected
>> to tolerate some ongoing changes and imperfect functionality in  
>> places.
>
> Yes, I think an announcement to R-sig is great idea.  My suggestion  
> for the delaying a CRAN release was based on how we've been making  
> sustained steady changes and we have a couple significant bugs  
> remaining.  Should either, our efforts flag, or we fix those bugs we  
> should submit the package to CRAN.
>
> [snip]
>
>> IMHO François' road map is a good road map to CRAN, coupled with  
>> fixing
>> any important bugs that we might come across in the process. The  
>> release
>> certainly doesn't have to be totally feature rich and flawless, but
>> making sure the core functionality is rock solid is important.  
>> Releasing
>> *tomorrow* seems a bit rushed for my tastes. First impressions can be
>> lasting! There are certainly R packages on CRAN that I've installed
>> once, been unimpressed with, and never tried again...
>
> Agreed.  I think regardless of disclaimers, (and personally I think  
> we should be in beta stage for a while) once a package is released  
> to CRAN there are expectations for basic level of quality.
>
> To me a 'release' means submitting to CRAN.  That said, I don't feel  
> strongly that we need to have the vignettes and unit tests completed  
> before we submit to CRAN, users are typically more forgiving about  
> poor documentation and unimplemented features than they are for  
> bugs.  So for me the only real release blockers are rerooting and  
> subsetting.
>
> If we wanted to we could pull rerooting and add it to the feature  
> request list.  But, subsetting feels more like a core function.
>
> Peter
>
>> François Michonneau wrote:
>>> Hi,
>>>
>>>  I think we should still plan of releasing it. My main concern is  
>>> that
>>> if we don't, we won't keep the pace we have been having in the last
>>> couple of weeks, and the official release will be delayed. If  
>>> people do
>>> start using it, then they will report bugs (not too many I hope) and
>>> keep development going.
>>>
>>>  However, I agree there is still some polishing to do before  
>>> officially
>>> releasing it. It would be valuable to identify what are the things  
>>> that
>>> we really need to change before the release. In my opinion, one of  
>>> main
>>> things is that we need to use consistent variable names for
>>> phylo4/phylo4d in our functions. They are currently called: x, phy,
>>> object, etc. I can imagine that it's confusing for new users  
>>> reading the
>>> documentation. This is important to do before the release because  
>>> if we
>>> harmonize these names in the future, we can break people code if  
>>> they
>>> use explicit variable names in their calls.
>>>
>>>  I agree that it would be nice to have our own subsetting and  
>>> rerooting
>>> functions. At this stage, however, it seems to me OK to release
>>> phylobase even if these 2 functions don't work. Most other aspects  
>>> of
>>> phylobase are functional and should allow people to start working  
>>> with
>>> it.
>>>
>>>  Because these functions don't work and yet are important, we should
>>> however probably release phylobase as a beta-1 version. Meanwhile,  
>>> we
>>> should think about a road map with our objectives for the future
>>> releases. I propose that we use the 0.4 release series as beta,  
>>> and have
>>> 0.5 series as the first official release.
>>>
>>> * beta-2 (0.4.2): non-unique labels, subsetting, rerooting
>>> * beta-3 (0.4.3): methods for multiPhylo4 and multiPhylo4d, no
>>> dependencies from APE, identify method
>>> * rc-1 (0.4.4): all functions have RUnit tests
>>> * rc-2 (0.4.5): complete documentation and vignettes
>>>
>>>  Alternatively, if we decide to not release quite yet on CRAN, we  
>>> can
>>> just send out announcements to the R-phylo mailing list and ask  
>>> people
>>> to test phylobase (from R-forge) and get their feedback.
>>>
>>>  Cheers,
>>>  -- François
>>>
>>>
>>> On Wed, 2009-08-26 at 23:00 -0700, Peter D. Cowan wrote:
>>>> This might be verboten to even suggest, but should we push off  
>>>> the release date?  In the last month we've made a 150 commits to  
>>>> phylobase, that's pretty awesome.  If we can keep up even a  
>>>> portion of this momentum, it may be worth while to hold off on  
>>>> releasing the package until we can finish a few things off.  Or,  
>>>> if we don't see ourselves having time at the moment, we can  
>>>> release as planned on Friday, and address the issues we've  
>>>> identified in a "Known Issues" section, and try to organize a  
>>>> 0.5.1 release down the road.
>>>>
>>>> Top on my list would be replacing our two ape dependencies.  The  
>>>> rerooting and subsetting are not trivial things to write, but the  
>>>> process of calling out to ape seems not to work the way we had  
>>>> hoped.  Unfortunately, I won't have time to do this until next  
>>>> week sometime.
>>>>
>>>> Cheers
>>>>
>>>> Peter
>>>> _______________________________________________
>>>> Phylobase-devl mailing list
>>>> Phylobase-devl at lists.r-forge.r-project.org
>>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Phylobase-devl mailing list
>>>> Phylobase-devl at lists.r-forge.r-project.org
>>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl
>> _______________________________________________
>> Phylobase-devl mailing list
>> Phylobase-devl at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl
> _______________________________________________
> Phylobase-devl mailing list
> Phylobase-devl at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl