Proposal 3: Dev Release Cycle #2793
Replies: 6 comments 2 replies
-
|
What are dev releases? |
Beta Was this translation helpful? Give feedback.
-
|
Dev releases are any PR committed, merged and released into the current dev branch. Currently we are at 6.0.0-dev.27. So the next PR that is approved, merged and released as 6.0.0-dev.28. |
Beta Was this translation helpful? Give feedback.
-
|
why and how do we distinguish between approvals of PRs to a dev branch or production? shouldn't there be one review process for changes that are slated for prod (ie in a Dev branch) or directly into prod? |
Beta Was this translation helpful? Give feedback.
-
|
My vote would be to continue with ad-hoc on demand dev releases. I don't see the need for weekly dev releases to be created. |
Beta Was this translation helpful? Give feedback.
-
|
Also agree with ad-hoc on demand dev releases, i.e. as current |
Beta Was this translation helpful? Give feedback.
-
@dschwartznyc These are releases marked as (x.0.0-dev.n), with x = 6 currently. They are aligned with the code committed on the 'master' branch, with is often also referred to as the 'dev' branch. |
Beta Was this translation helpful? Give feedback.
-
|
@lolabeis thanks for clarifying. Since the intention for the label is to tag code for a future major release, perhaps the use of "dev" creates confusion in terms of the approval process. FWIW, in my experience "dev" has been associated with code contributed but not yet reviewed. Regardless, suggest closing this issue (Dev Release Cycle) as it would seem to be covered in a combination of #2792 - PR approvals and #2794 - Prod Release Cycle . |
Beta Was this translation helpful? Give feedback.
-
|
As explained previously, dev releases in this context are not code contributed but not approved, they are PRs that have been reviewed and approved and tagged, (x.0.0-dev.n). |
Beta Was this translation helpful? Give feedback.
-
Current: Dev minor and patch release are ad-hoc.
Proposal: Dev minor releases and unreleased patches will be automatically released weekly unless there are no approved PRs. Patches can be released as needed. Minor and patch releases must be backward compatible.
Proposed rewording : Approved minor changes and patches will be automatically released into dev weekly (unless there are no approved PRs). Urgently needed patches can be released as needed on approval from two maintainers. Minor and patch releases must be backward compatible.
Chris: I’m struggling to understand the need for scheduling these. I’m guessing the issue is that once a PR is merged there can often be a delay before it is put into a dev release i.e. the build process is run? In which case I think Brian’s wording is better. I’m also trying to understand what a dev minor release is? So if we have version 6.0.0-dev.nnn as the dev major version, are we referring to 6.1.0-dev.nnn as the minor release? For there to be a 6.1.0-dev though we would have to have already put 6.0.0 into production. So I think this is actually just referring to dev upgrades in general e.g. 7.0.0-dev.123, 6.1.0-dev.321?
AH: I do not understand what we want to achieve by having a weekly cycle instead of the current way. We would have fewer dev releases, and multiple changes would be bundled together in a release. This comes with the downside that @dan mentioned above, but I don't see the upsides.
I agree with @ahutusoru123. Not sure why we need to establish a weekly cycle. Is this a cost issue?
David: Agree with Chris that there is no such thing as a minor or patch release for Dev. We only increment one “x” tag in 6.0.0-dev.x. We don’t see the use-case for enforcing a release schedule for these. Also no backward-compatibility requirement (that’s the point of having a dev branch to make those changes)
Result: Seems fewer participants support regularly scheduled releases and instead prefer an ad-hoc approach. If the majority agrees we will continue with on-demand, as needed dev releases.
Beta Was this translation helpful? Give feedback.
All reactions