This does seem really useful. I appreciate the detailed explanations. If we formalize it into policy, I'd love to make it a bit more concise, and with appropriate room for human contestation of the guidelines.
On Fri, Jun 1, 2018 at 1:47 PM Scott Wegner <sweg...@google.com> wrote: > 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 >>> >>
