search

natverse / neuprintr

R client utilities for interacting with the neuPrint connectome analysis service
http://natverse.org/neuprintr
3 stars 3 forks source link

More elaborate workflow? #60

Open romainFr opened 4 years ago

romainFr commented 4 years ago

@jefferis @alexanderbates I was wondering, given the rate of change on that repo and the fact that people are already using it to analyze data, if we should think about some more elaborate workflow? Maybe push the day to day on a dev branch (meaning merge PR into dev instead of master), and only push things to master once they're stable -- together with documentation of the possible necessary changes in existing analysis code. Thoughts?

jefferis commented 4 years ago

Yes, I think a dev branch with named releases on master would probably be a good idea.

The most important things is that we need to get tests for all functions against the neuprint server. There are still a few breakages for things that people have apparently not been using. Looking at https://codecov.io/gh/natverse/neuprintr/tree/master/R could help.

alexanderbates commented 4 years ago

I am on board with this

jefferis commented 4 years ago 
 together with documentation of the possible necessary changes in existing analysis code. Thoughts?

it would be really helpful to have more examples somehow of analysis code that could break because I still see some things that I would like to change that will cause breakage. Example

neuprint_connection_table() and neuprint_simple_connectivity() both have a prepost=c("PRE","POST") argument. People always get confused by this (I think input/output or upstream/downstream are much better) and in fact neuprint_simple_connectivity() is implemented backwards right now. I would like to try and get this cruft cleaned up ASAP to avoid pain later on when we are really close to deadlines!

jefferis commented 4 years ago

See #59 for the above. The other change that I would like to address ASAP is #50 since this will also cause breakage. But it seems to me sensible to try to standardise column names as much as possible now.

jefferis commented 4 years ago

I propose that we release a new version in the next 24h. Then after that release we switch to a more conservative workflow with a dev branch. Ideally we would switch the default branch but I do not recall if master will continue to be the default for installations via the remotes package from R. The situation that we want is that dev is the default for PRs etc and master is the default for remotes::install_github

jefferis commented 4 years ago

I have now protected the master branch by default so that the travis build must pass before merges are allowed.