-
Notifications
You must be signed in to change notification settings - Fork 126
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
Consider using release branches #1124
Conversation
0f49f57
to
2d1899c
Compare
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
🚨 1 ALERT: Threshold Boundary Limit exceeded!
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
Bencher
Click to view all benchmark results
Bencher - Continuous Benchmarking View Public Perf Page Docs | Repo | Chat | Help |
RELEASE.md
Outdated
- Constrain each development cycle to a fixed time period, after which a release | ||
is made. Typically, the development cycle is 6-8 weeks long. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that if we release ONLY on 6/8 weeks we will find ourself rushing to get PR merged nearby the release. That of course will impact the quality of the code. For example if we have a feature that we need and is almost ready and release is in 3 days we will do everything possible to have it in the next release otherwise we will have to wait 8 weeks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we should aim to a more precise time frame for future releases (even if it's generally hard in a FOSS environment), and 6 to 8 weeks looks reasonable to me. If we will encounter some barriers as the one mentioned by @Fi3 I'm pretty sure we could postpone the specific release a little bit. At the end we will keep asserting the progress on every dev call as usual. As a general guideline, I would leave it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO having shorter release cycle solve better this issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not too opinionated on this, but is seems a reasonable middle ground between the arguments presented so far would be to:
- aim for 4/6 weeks (shorter cycle)
- if some specific task is taking longer than expected, we postpone it to the next release (so that we're not rushing anything)
what do you guys think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would wait for @pavlenex input, he's definitely the one with more experience regarding time frames and roadmap definition in FOSS 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if some specific task is taking longer than expected, we postpone it to the next release (so that we're not rushing anything)
yep this is ideal and should be always like that but there is a positive correlation between the length of release cycle and the willinges to ignore best practice and rushing thing to not miss the release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems @pavlenex won't be available to provide his input
for now, let's avoid blocking this PR because of this
let's just remove this phrase about release timeline
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems @pavlenex won't be available to provide his input
for now, let's avoid blocking this PR because of this
let's just remove this phrase about release timeline
Agree 👍
concept ack |
dd337a2
to
ce13eb9
Compare
ce13eb9
to
fb2b32b
Compare
fb2b32b
to
ecd3e4d
Compare
Use release branches on every new release, creating branch/tag for every release. This change also eliminates the `dev` branch and suggest to only maintain `main` branch.
ecd3e4d
to
4e34e3d
Compare
and maintain only
main
withoutdev
branch.relates to #1098