metasyn icon indicating copy to clipboard operation
metasyn copied to clipboard

Published 20 hours ago • verified publisher icon sodascience

Development branch

Open qubixes opened this issue 1 year ago • 5 comments

I have asked again for some feedback on metasyn (in terms of documentation). One thing that stood out was that the documentation is currently ahead of the code, so that it doesn't work correctly when you follow the new instructions with the old code (on PyPi). While we can make more releases, another solution would be to start using development branches. We would only merge to the main branch during a release. What are your thoughts?

qubixes avatar Mar 19 '24 10:03 qubixes

Yes, I have been thinking exactly this for a few days now. We can do several things to organize our dev side:

  • #279
  • Have another look at simplifying our checks / lints: more ruff less other stuff
  • Maybe move to a fork way of working? So no branches on sodascience/metasyn except for the below proposal?
  • #281
  • #282

Proposal

  • have two branches: main and dev. (or prod and dev)
  • dev branch is basically what our main is currently
  • dev is supposed to be "quite stable", but some temporary bugs / stuff not working is allowed
  • main branch always works, not allowed to fail any tests.
  • main branch is always up-to-date with latest pypi release, latest docker, latest github release. Basically: pushing to main is equivalent to creating a new release (through Continuous Deployment / GH action)
  • main accepts only PRs from dev in principle, except for bugfixes
  • update to main triggers renewed CI/CD in plugin repos to check if they still work.
  • PRs to main need approval by either @qubixes or @vankesteren
  • ensure we have two strands of docs on readthedocs: stable (corresponding to our main branch) and dev (corresponding to our dev branch)

Let me know if you think something else! (probably 😄)

vankesteren avatar Mar 20 '24 08:03 vankesteren

@vankesteren Yes, agree mostly with the proposal. One thing I would change:

  • The dev (or I would call it develop) branch should not fail any tests either.
  • Ideally PRs into dev would also have approval from a maintenance reviewer.

I'm fine with working in forks, it has been a while!

qubixes avatar Mar 20 '24 10:03 qubixes

Yeah, just to keep the repo clean you know, so i dont have to go and delete stale branches every other week 😛

vankesteren avatar Mar 20 '24 11:03 vankesteren

I don't think that would be my most important reason, but I suppose we should follow the leave-no-trace principle!

qubixes avatar Mar 20 '24 13:03 qubixes

Let's do this as well with our optional dependencies:

https://github.com/asreview/asreview/blob/d84c41a78940649a910e77748012a1945535139e/pyproject.toml#L134C1-L156C2

vankesteren avatar Mar 28 '24 14:03 vankesteren