Thanks Cham. Overall this seems like a useful hygiene improvement for the project. I've left some comments in the doc.
On Fri, Jun 1, 2018 at 10:48 AM Chamikara Jayalath <chamik...@google.com> wrote: > 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 >> >
