Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Development branch #278

Closed
qubixes opened this issue Mar 19, 2024 · 5 comments
Closed

Development branch #278

qubixes opened this issue Mar 19, 2024 · 5 comments
Assignees
Labels
discussion Discussions about how to move ahead priority
Milestone

Comments

@qubixes
Copy link
Member

qubixes commented Mar 19, 2024

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 qubixes added priority discussion Discussions about how to move ahead labels Mar 19, 2024
This was referenced Mar 20, 2024
@vankesteren
Copy link
Member

vankesteren commented Mar 20, 2024

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

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 😄)

@qubixes
Copy link
Member Author

qubixes commented Mar 20, 2024

@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!

@vankesteren
Copy link
Member

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

@qubixes
Copy link
Member Author

qubixes commented Mar 20, 2024

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

@qubixes qubixes added this to the Metasyn 1.1 milestone Mar 25, 2024
@vankesteren
Copy link
Member

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

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

@qubixes qubixes closed this as completed Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussions about how to move ahead priority
Projects
None yet
Development

No branches or pull requests

3 participants