various packaging questions

[paciorek]

@perrydv @danielturek @dochvam A few questions about nimbleSMC:

1. We currently have nimbleSMC at version 0.0.1. I'm inclined to either start at 0.1.0 or 0.10.0, the latter indicating branching off our our main package.
2. nimbleSMC is its own repository yet we have the nimble/packages/ structure within the nimble repo, so we could put nimble/packages/nimbleSMC there. The packages would be separate but commits would be going to the same repository. I think it makes sense to have a separate repo but wanted to check.
3. Assuming we have a separate repo, my plan is to create nimbleSMC/packages/nimbleSMC to mimic the nimble repo directory structure. 4) Who should be the maintainer? Ben put himself down, but it probably makes most sense in terms of longevity and consistency with nimble itself (given that nimbleSMC is so closely aligned with nimble) for me to do it. 5) @dochvam , why is devtools needed as a 'depends'? 6) Given the new package, we need to move Dao from authorship on nimble to authorship on nimbleSMC. I am doing that. 7) Help on SMC samplers is under help(SMCsamplers) (as well as help(RW_PF)). @danielturek what do you think?

Thoughts?

[danielturek]

@paciorek @perrydv @dochvam

1. I'm fine with starting the nimbleSMC numbering at either 0.1.0, or 0.10.0, although I probably prefer the former (0.1.0).
2. I think a separate repository called nimbleSMC is the way to go. I would put this new repo under the nimble-dev organization, but definitely distinct from nimble.
3. Yes, the directory structure of nimbleSMC/packages/nimbleSMC makes the most sense.
4. Any decision on who is the maintainer seems fine to me, depending on what Ben thinks.

..7. That sounds reasonable. I'm assuming help(SMCsamplers) gives help on both SMC samplers, and help(RW_PF) and help(RW_PF_block) give help on each specific samplers. Is that the idea?

[paciorek]

Thanks @danielturek .

I'm very close to being able to submit this (first) and nimble itself (next) to CRAN, once we finalize these last questions.

[dochvam]

2: Having a separate repo seems wise for the sake of distinct testing/workflows. 3: Out of curiosity, what's the function of the nimble/packages/nimble convention? 4: I'd prefer not to be the maintainer; I put myself down to receive Travis update emails during development 5: I had devtools in depends because I was installing the nimble/noSMC branch on Travis for testing using install_github(). Once noSMC is merged to master, devtools can definitely be removed, and the file run_tests.R should be modified to remove the line where that's called. I'm now thinking this might have to wait until the noSMC changes are on CRAN. If it's reasonable, the easiest thing to do would be to leave in the devtools dependency / install_github call until the release of noSMC; or, we could change the plan and release nimble 0.10.0 first.

[paciorek]

Regarding the timeline, here is what I was thinking but I may be missing something:

0.) merge in noSMC branch to devel. This is done. 1.) test nimbleSMC against the noSMC version of nimble. I've done this locally and things seem fine. 2.) release nimbleSMC to CRAN (removing devtools dependency, etc.) 3.) release nimble to CRAN

If the reason to release nimble first is so that we can test nimbleSMC via Travis, I don't think that is necessary. But does anyone see another reason we should release nimble first?

[dochvam]

You're right. I was forgetting that nimbleSMC is totally compatible with the current NIMBLE release and thinking incorrectly that testing nimbleSMC against nimble 0.9.1 would error, which it shouldn't.

[paciorek]

Actually, this discussion is making me realize that nimbleSMC won't pass R CMD check using nimble 0.9.1 because of pesky issues related to exports and a change in the function signature of decideAndJump.

So I think we need to release nimble 0.10.0 first. That means that SMC functionality will be briefly unavailable. I think that is ok.

[paciorek]

Decided to do 0.10.0 in zoom call.