dsBetaTest v0.3.0

Support Developer support
1

I have just wrapped up the most recent commits into a new release:

You should be able to reference this tag from your opal installs in the usual way.

One minor (hopefully) change is that I have added a ‘release’ branch which is a bit more stable than the master. People seem happy enough merging to the master, and it might break from time to time, but the intention is the release branch will only get updated when tests have been passed. Comments on this very welcome!

2

Hi,

There is an inconsistency: release tag is 0.2.1 but the DESCRIPTION file says that the version is 0.3.0.

Best Yannick

3

Ha! I don’t know why I called this 0.2.1, it should have always been 0.3.0. I have now re-tagged and re-released. Thanks for the spot Yannick.

4

Excellent. dsBetaTest* packages 0.3.0 are available in the cran.obiba.org.

Yannick

5

It looks like a lot of good things have been happening on the DataSHIELD Github, both new code and tools to help quickly set up infrastructure.

I was wondering about the process by which the dsBetaTest* repositories will become the final releases? I am not a Git expert, but might expect to have a BetaTest branch in dsClient and dsServer, which would then get merged into master and marked as a release when ready? And other development branches that get merged into the BetaTest branch when the new functionality is ready for testing? Or is the idea that this way makes it easier for people to get install the BetaTest versions on Opal?

It might be that I have missed some aspect of how the development is being done, but am trying to think ahead to when others might be contributing work, and when there are lots of people wanting to install the latest release.

6

Hi Tom. It’s a good question, and one I have pondered a fair bit myself. I think we are slowly developing a relatively pragmatic way of getting people involved, but I could easily be swayed! The current thinking is along the lines of:

  • Stuff in BetaTest is dangerous and should be used with extreme caution, so keeping it as a separate repo helps emphasize that.
  • We’ve been putting in place a continuous integration testing framework which will mean that if anything changes in the stack we should automatically pick it up. e.g. if an update to one of the OS, opal, R, DS, dependent libraries etc changes the output of a DS function we will know about it. This has been easier to build in one repo to begin with, and is starting to highlight issues early.
  • Git is quite new to some developers, so pointing them to one repo to do development work makes it a little easier. This is also the reason I have started to trial a ‘release’ branch, people get the idea of a master branch and I don’t want to confuse things by having a ‘merging’ branch or similar instead.

Where I see it going is something like:

  • We will roll out the CI testing to all the repos.
  • Functions will only exist in the BetaTest repos for a while - once we are happy they work properly we will move them over to the main repos and do a new release.

I really would welcome comments on this as I could be well off what others think is useful!

7

The cran.obiba.org package index was broken, not sure why. I have redeployed and now dsBetaTest install works. Yannick

8

Hi Olly, I can definitely see some advantages in doing it this way. I think at the moment my main concern is that might be some manual work required to get the functions out of the BetaTest repos and into the main repos, and this could open up scope for errors to creep in. Or can you do this with a pull request, to make sure the right code goes across?

I guess like with a lot of things, it might be good to run the process through and then see what needs to change in the future!

9

Yeah, I may well change my mind once I have tried it once!