Proposal 4: Prod Release Cycle #2794
Replies: 4 comments 1 reply
-
|
Why is there a separate approval process for minor and patch releases? Can't they go into production once they have been approved? |
Beta Was this translation helpful? Give feedback.
-
|
Release date and content to be agreed by all SWG applies to major releases. |
Beta Was this translation helpful? Give feedback.
-
|
Major versions (n.0.0) going through the SWG seems to be agreed. Minor versions (0.n.0) I would also put through the SWG. I'd be okay with Patches going through the CRWG (0.0.n). I think our guideline should be one major release a year but this does not preclude more major releases if we need them |
Beta Was this translation helpful? Give feedback.
-
I vote for keeping minor (0.n.0) through the CRWG, as currently, rather than elevate to the SWG.
I vote for patch to go through without the need for a CRWG, since by definition a patch should be (i) urgent and (ii) not modify existing functionality other than fixing a bug. It still needs approval from maintainers. |
Beta Was this translation helpful? Give feedback.
-
|
Agree that bug fixes need to be as expedient as possible. In my experience bug fixes can often modify existing functionality though - but as you suggest, the maintainers can determine this and decide whether a patch needs to go through the CRWG or not. The roadmap is defined by the SWG which is why I was thinking minor releases would be best going through the SWG. Once their content has been agreed then the individual PRs that make it up can be approved/collated by the CRWG. |
Beta Was this translation helpful? Give feedback.
-
Current: Prod releases occur approximately once per year but date is not fixed
Proposal: Prod minor releases will be based on contributor request and approval by CRWG. Prod major releases will occur once per year on a fixed date set by the Steering Committee. Where a non-backward compatible change is approved, an ad-hoc prod release can be requested.
BL:>> I would propose the following:
Prod minor releases:
Planned changes will be promoted from dev to prod on a frequency/schedule to be agreed by the CRWG based on the planned work. The planned minor releases should be made no more than weekly and ideally within one month of promotion to dev. Unplanned changes (patches) to correct issues can be made more quickly, with approval by two maintainers, depending on the severity of the issue. Critical and severe errors (those preventing CDM to be used for its core mission) can be corrected without first deploying to dev, with approval of the maintainers. Less severe issues should first be deployed to dev prior to promotion to prod.
Chris: I would suggest that anything going into production should be agreed by the SWG and not just the CRWG. The CRWG can review individual PRs, but agreement of when to cut a new prod release (major/minor/patch) should be approved by the SWG. This in turn may mean that ad-hoc meetings of the SWG are required to approve delivery of a new prod release. In general I’m likening the SWG to the Product Owner of the CDM, and in my experience anything going into production would need to be approved by the product owner.
DS: Please clarify what is meant by "Dev minor releases" as it seems to imply constraints on releases of code in development and one would think that these should take place with no constraint to facilitate collaboration and testing.
WRT changes to production code:
Patches and Minor changes: please confirm that patches and minor releases will be released to Production on at least a weekly basis with the potential that patches can be released immediately to production depending on the severity of the defect to be resolved.
Major changes: is the proposal to restrict major releases to once annually? If so, it would seem to limit CDM's adoption and development. Instead, perhaps it would make sense to have at least one annual release with more at the discretion of the SWG.
MG: If we want to expand the adoption, we cannot have only one Production version per year. Since we are generating new content rapidly, production versions will need to be generated more frequently than when the standard is more mature. We've seen this in other financial standards such as FpML and FIX. The CDM Roadmap based on content should define the timeline for Prod releases based on the timeline for adding new content that is needed to implementers. For example, the Collateral WG may want to have a Prod release in the summer and the Products and Events sooner than that. The CDM Roadmap should include an attempt to schedule the expected Prod releases for the year based on the book of work of each working group.
David:We don’t agree with the proposed change, we broadly agree with Brian’s proposal, but we don’t agree with Chris’s proposed alternative 🙃.
Prod release once per year at a fixed date: It should be roadmap-based instead and driven by the SWG – see Brian’s suggestion for prod major release below.
Agreement of when to cut a new prod release (major/minor/patch) should be approved by the SWG: We think that should only apply to major (see roadmap comment above), not minor or patch. While I agree that the SWG acts as a PO, it should not be in the minutiae of minor or patch changes to Prod, which by design should be backward-compatible anyway – it delegates authority to the sub WGs for that. Where the SWG should be invoked ad-hoc is if a minor or patch release is required that breaks backward-compatibility – which should be on an exception basis. Effectively it’s equivalent to cutting a new major earlier than anticipated – Brian also covers that case below.
In summary SWG should agree and set the road-map but CRWG should be in charge of collating content for and executing the release. Similar to the manner in which it has recently started to do so.
Results:
SWG to decide on major releases, release date and content.
Patches and minor changes targeted to production and approved by maintainers can go directly to production.
Beta Was this translation helpful? Give feedback.
All reactions