Hi All, I've copied ideas proposed in the doc below for more visibility. Any comments are welcome.
* - Human readable per-SDK reports on status of Beam dependencies are generated weekly and shared with the Beam community through the dev list. These reports should be concise and should highlight the cases where the community has to act on. See [4] for more details on this.- Beam Components (IO connectors, runners, etc) should always try to use versions of dependencies that are defined at the top level. Per-component dependency version overrides should only be performed in rare cases and should come with clear warnings for users.- Upgrading a dependency with an outdated major version becomes a blocker for next major version release of Beam and for any minor version releases after next immediate minor version release. For example, if a dependency is identified to be outdated while the latest release is x.y.z, upgrading this dependency becomes a blocker for releases (x+1).0.0 and x.(y+2).0 of Beam. Additionally, upgrading to a major version of a dependency will only be enforced if the new major version of the dependency can be adapted without a significant rewrite to any Beam component. Note that this policy intentionally allows one of the minor version releases to proceed without upgrading the dependency which I believe will give Beam community enough breathing room to upgrade dependencies without significantly affecting the release frequency.- Upgrading a dependency with a significantly outdated minor version (based on methodology defined in [4]) becomes a blocker for next major version release of Beam and for any minor version releases of Beam after next immediate minor version release. Note that this policy does not force Beam to adapt every minor version release of a dependency.- When performing a release, release manager should make sure that blockers identified through above process are resolved before the release candidate is cut.- Optionally, dependency declarations may have comments that identify owners that should be responsible for upgrading the respective dependencies. Release manager may choose to assign a blocking JIRA for a dependency to its owner.* Thanks, Cham On Thu, May 31, 2018 at 7:11 PM Chamikara Jayalath <chamik...@google.com> wrote: > Hi All, > > We recently ran into many issues due to Beam dependencies being > significantly out of date. For example see [1], [2], and [3]. > > Yifan Zou recently introduced a proposal [4] that would allow us to > identify outdated dependencies. But to really make sure that this helps the > Beam project and community I believe we should adapt several small policy > changes to our development and release process. > > To this end, I have created following short document that identifies the > dependency issue and proposes several policy changes. I greatly appreciate > if you can take a look and comment. > > > https://docs.google.com/document/d/15m1MziZ5TNd9rh_XN0YYBJfYkt0Oj-Ou9g0KFDPL2aA/edit?usp=sharing > > Thanks, > Cham > > [1] https://issues.apache.org/jira/browse/BEAM-3098 > [2] https://issues.apache.org/jira/browse/BEAM-3991 > [3] https://issues.apache.org/jira/browse/BEAM-4229 > [4] > https://lists.apache.org/thread.html/758625106a6cfe9ba23d7b39625da20e050c6279b138b18b3f0013e7@%3Cdev.beam.apache.org%3E >
