I like the idea of releasing Statefun more frequently to have faster feedback cycles!
No objections for releasing 2.1.0 from my side. On Wed, May 20, 2020 at 2:22 PM Tzu-Li (Gordon) Tai <tzuli...@apache.org> wrote: > Hi devs, > > Since Stateful Functions 2.0 was released early April, > we've been getting some good feedback from various channels, > including the Flink mailing lists, JIRA issues, as well as Stack Overflow > questions. > > Some of the discussions have actually translated into new features > currently being implemented into the project, such as: > > - State TTL for the state primitives in Stateful Functions (for both > embedded/remote functions) > - Transport for remote functions via UNIX domain sockets, which would be > useful when remote functions are co-located with Flink StateFun workers > (i.e. the "sidecar" deployment mode) > > > Besides that, some critical shortcomings have already been addressed since > the last release: > > - After upgrading to Flink 1.10.1, failure recovery in Stateful > Functions now works properly with the new scheduler. > - Support for concurrent checkpoints > > > With these ongoing threads, while it's only been just short of 2 months > since the last release, > we (Igal Shilman and I) have been thinking about aiming to already start > the next feature release (2.1.0) soon. > This is relatively shorter than the release cycle of what the community is > used to in Flink (usually 3 months at least), > but we think with the StateFun project in its early phases, having smaller > and more frequent feature releases could potentially help drive user > adoption. > > So, what do you think about setting feature freeze for StateFun 2.1.0 by > next Wednesday (May 27th)? > Of course, whether or not to actually have another feature release already > is still an open discussion - if you prefer a richer feature release with > more features included besides the ones listed above, please do comment! > > Cheers, > Gordon >
