You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was thinking that maybe we could start doing the development like in Biopython, where changes are made in PRs to master, which has all branch protections instead of dev_bjorn. As far as I know, committing to master does not trigger a pypi release, so I think it would be OK to have master be the "next" codebase and pypi version the "stable" one.
What do you think? I mean this mostly because otherwise dev_bjorn is unprotected and can be force-pushed by accident. Putting protection in dev_bjorn would not be great, because then if it diverges from master there is no way to fix by rebasing if it has branch protections.
The text was updated successfully, but these errors were encountered:
I agree in principle, but I would like to investigate if the Biopython way is the most common way to set up a collaborative project? Is there a "standard way" or workflow akin to "Gitflow" for example?
The "master is dev, release is stable" is what I have seen in the repositories I have contributed:
Gene ontology and other ontology repos
BioPython
OVE and other teselagen tools
LinkML
I think gitflow might be a bit overkill for a library with few regular contributors. Also becaus most of what we add are incremental improvements and bug fixes, not so much new features. For the big new assembly model change I can keep a feature branch in parallel for the implementation when I get to it.
Hi @BjornFJohansson,
I was thinking that maybe we could start doing the development like in Biopython, where changes are made in PRs to master, which has all branch protections instead of dev_bjorn. As far as I know, committing to master does not trigger a pypi release, so I think it would be OK to have master be the "next" codebase and pypi version the "stable" one.
What do you think? I mean this mostly because otherwise dev_bjorn is unprotected and can be force-pushed by accident. Putting protection in dev_bjorn would not be great, because then if it diverges from master there is no way to fix by rebasing if it has branch protections.
The text was updated successfully, but these errors were encountered: