marbl / Mash

Fast genome and metagenome distance estimation using MinHash
mash.readthedocs.org
Other
385 stars 91 forks source link

Github flow #51

Open positiveblue opened 7 years ago

positiveblue commented 7 years ago

Now that more than one person is going to contribute to the project and more than one change is going to be done would be great to have a clear github-flow.

The standard in many projects is to keep two branches: Master and Development. The master is equivalent to the releases meanwhile the development goes ahead with the last stable features in the project. Each time that a functionality has to be added a new branch is created from development and they merge when the feature is working.

I have no permissions so @ondovb should create it.

Does it seem right for you?

ondovb commented 7 years ago

Hi Jordi, We currently use a tagged release model rather than a stable tip, so it's fine just to have new features in master. Also on that note, do you think it would work to have a separate project for mashpy that included mash as a git submodule? As long as the API code doesn't need to modify the base mash source, I think that might be easier all around, since you wouldn't have to worry about pull requests.

positiveblue commented 7 years ago

Hello @ondovb

There is no problem at all in having in working it in a separated repo. It is true that we do not have to worry about pull requests then but I will relay on you in modifying the C++/C API. If the idea is to have mashpy totally separated I agree on it but there are things like the CMake building process, the C++ tests, the CI Server that should be in the main project.

What do you think about me doing all this work in my own fork of the project and if we see that it is useful for the main project ending merging some of the features?

ondovb commented 7 years ago

Yes, I think the fork makes sense for now, and I can merge things when I get time to look closer.