MATLAB code: what should we do about it?

[jeremymanning]

Should we maintain separate MATLAB and Python codebases? The original MATLAB code is already released here: https://www.mathworks.com/matlabcentral/fileexchange/56623-hyperplot-tools

The current Python toolbox goes way beyond the original MATLAB code, and our lab is no longer using MATLAB anyway. So I'm inclined to have us remove the MATLAB code from this repository and just have it be a Python repository.

In a future release we could provide wrappers (for MATLAB, Javascript, R, etc.) for the Python code if we wanted to support those languages; that would allow us to maintain a single "main" codebase without re-writing everything multiple times.

My proposal is that we replace the entire repository with the the current python directory. We could also add a link to the original MATLAB code in the readme or in our writeup.

Thoughts?

[andrewheusser]

I think at least maintaining separate code bases (matlab/python) is probably a good idea. I'm hesitant to toss the MATLAB code out completely, since the majority of the cog neuro community (who may find this tool useful) uses MATLAB primarily. Maybe we can host the MATLAB release on github, but not extend it beyond its current status unless there is a demand for it?

[jeremymanning]

the matlab code in this repository is exactly overlapping with the fileexchange code...so if people want the matlab version they can go to the fileexchange (especially if we link to it). i'd also be fine to host the matlab code on github and then connect the fileexchange version to that.

[jeremymanning]

i'll make a new repository for the matlab code...

[andrewheusser]

we could copy the current codebase as a branch called v1.0, and then all changes to master would be towards a v2.0 release

[andrewheusser]

(future changes)

[jeremymanning]

that seems messy...what about if we just have master be the main branch, and then any time we make changes we branch master and then pull the changes back in?

[andrewheusser]

i guess what i mean is we should have a copy of the 'v1' code somewhere on github that we dont ever change. that way, we know what features are in that version, bugs, etc. we could then maintain master and feature branches...and merge the feature branches into master until master is mature enought for a v2 release

[jeremymanning]

the matlab code is now here: https://github.com/ContextLab/hypertools-matlab

it probably needs to be cleaned up (all i did was copy it from the matlab folder). when we release the python code we can also set that repository to "public". or i'm also happy to set it to public now...i just didn't want us to scoop ourselves or confuse people.

[andrewheusser]

another way to do it would be to maintain a 'releases' folder on master, to which we add a copy of each version that we release

[andrewheusser]

ya, i think holding off on making it public makes sense (and release it along with teh python code)

[jeremymanning]

i like this idea-- but there's an "official" way to do this: https://help.github.com/articles/creating-releases/

[andrewheusser]

ah great!

[jeremymanning]

we could actually try it out for v1...we just need to tag it as a "pre-release" that's not yet ready for production (there's a way to do that)

[andrewheusser]

cool, i think we should try it for v1

[jeremymanning]

👍

[jeremymanning]

you are go for launch*

*of getting the v1 release tagged as a "release"

🚀

[andrewheusser]

v1 official release noted, matlab code moved out of repo, closing this issue