+1. Release notes from jira may be hard to digest for people outside the project. A short summary for may be really helpful for those considering Beam or loosely following the project to get an understanding of what is happening.
It also presents a good opportunity share progress externally, which may attract more users to try things out. On Mon, Jan 29, 2018, 9:11 AM Kenneth Knowles <[email protected]> wrote: > +1 I like the idea and agree with adding it to the release guide. Even a > very short post the length of an email is nice. We could have a template to > make it very easy. > > On Mon, Jan 29, 2018 at 8:02 AM, Romain Manni-Bucau <[email protected] > > wrote: > >> +1 to have it as a best effort - most of projects do. But as JB said, if >> it slows down the release motivation it shouldn't be enforced but just >> encouraged. A good solution Ismael is you take this responsability for the >> coming releases after the release manager is done with the annoucement. >> This way we have the best of both worlds :). >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://rmannibucau.metawerx.net/> | Old Blog >> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> >> >> 2018-01-29 15:02 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: >> >>> Hi Ismaël >>> >>> The idea is good, but the post should be pretty short. Let me explain: >>> >>> - We will have a release every two months now, so, some releases might be >>> lighter than others, and it's normal >>> - the Jira Release Notes already provides lot of details >>> >>> For instance, in Apache projects like Karaf, Camel, and others, we do the >>> announcement of a release on the mailing lists with the release notes >>> linked. >>> Sometime, we do a blog to highlight some interesting new features, but >>> it's not >>> systematic. >>> >>> So, I agree: it's a good idea and I would give some highlights about >>> what we are >>> doing and where we are heading. However, I don't think we have to >>> "enforce" such >>> blog post for every single release. It's a best effort. >>> >>> My $0.01 ;) >>> >>> Regards >>> JB >>> >>> On 01/29/2018 02:47 PM, Ismaël Mejía wrote: >>> > This is a fork of a recent message I sent as part of the preparations >>> > for the next release. >>> > >>> > [tl;dr] I would like to propose that we create a new blog post for >>> > every new release and that this becomes part of the release guide. >>> > >>> > I think that even if we do shorter releases we need to make this part >>> > of the release process. We haven’t been really consistent about >>> > communication on new releases in the past. Sometimes we did a blog >>> > post and sometimes we didn’t. >>> > >>> > In particular I was a bit upset that we didn't do a blog post for the >>> > last two releases, and the list of JIRA issues sadly does not cover >>> > the importance of some of the features of those releases. I am still a >>> > bit upset that we didn't publicly mentioned features like the SQL >>> > extension, the recent IOs, the new FileIO related improvements and >>> > Nexmark. Also I think the blog format is better for ‘marketing >>> > reasons’ because not everybody reads the mailing list. >>> > >>> > Of course the only issue about this is to decide what to put in the >>> > release notes and who will do it. We can do this by sharing a google >>> > doc that everyone can edit to add their highlights and then reformat >>> > it for blog publication, a bit similar to the format used by Gris for >>> > the newsletter. Actually if we have paced releases probably we can mix >>> > both the release notes and the newsletter into one, no ? >>> > >>> > What do you think? Other ideas/disagreement/etc. >>> > >>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >> >> >
