There is a chicken-and-egg problem here. The solution may be that the only 'release notes' we have for a patch release like this are links to the JIRA query and the Github tags which will show the changes. Those two URLs can be predicted ahead of time and will still work even if we have to go through multiple RCs. This helps us to stick to not introducing new features or incompatible changes in patch releases, since we would have no mechanism to document them. We can also add a Release Notes field to JIRA so that people can see a draft of the release note for a given issue before it is even part of a release.
On Fri, Mar 4, 2016 at 10:33 AM, Jean-Daniel Cryans <[email protected]> wrote: > I talked more to Todd offline, for 0.8.0 we'll try our best to have release > notes to be in a releasable format so that it's easy to get them in before > cutting an RC. > > For 0.7.1 I'm asking for a free pass OR we sink it right away, push the > release notes ASAP, and roll out a new RC with a 24h voting period. > > J-D > > On Fri, Mar 4, 2016 at 10:24 AM, Mike Percy <[email protected]> wrote: > > > Our release notes come bundled with the source package. In this case our > > notes are there in docs/ but it seems strange to only have 0.7.0 relnotes > > in a 0.7.1 release tarball. > > > > Mike > > > > Sent from my iPhone > > > > > On Mar 4, 2016, at 6:21 PM, Jean-Daniel Cryans <[email protected]> > > wrote: > > > > > > I feel strongly against having to have the release notes updated on the > > > website before being able to roll out an RC. It always takes at least > one > > > day to get reviews for that, more on big releases. Then, following RCs > > > might also need to have the notes updated, which delays things even > more. > > > > > > If folks care about having some minimal form of release notes, we can > do > > > something similar to what HBase does: > > > https://github.com/apache/hbase/blob/master/CHANGES.txt > > > > > > J-D > > > > > >> On Fri, Mar 4, 2016 at 8:07 AM, Todd Lipcon <[email protected]> > wrote: > > >> > > >> Perhaps we can keep voting on this release, finish up the release > notes > > >> today, and have a quick turnaround on rc2? I imagine if the diff > between > > >> the tags is only in the docs/ directory, we can get the voting done > in a > > >> couple hours (just verify the sha/signature, no need to rebuild and > > retest > > >> if the code is identical) > > >> > > >> -Todd > > >> > > >> On Fri, Mar 4, 2016 at 6:30 AM, Jean-Daniel Cryans < > [email protected] > > > > > >> wrote: > > >> > > >>> Just planning on pushing them to the website when 0.7.1 is > available.. > > >>> > > >>>> On Fri, Mar 4, 2016 at 1:49 AM, Mike Percy <[email protected]> > wrote: > > >>>> > > >>>> Or maybe what you're saying is that you're already planning for an > > RC2. > > >>>> > > >>>>> On Fri, Mar 4, 2016 at 11:47 AM, Mike Percy <[email protected]> > > wrote: > > >>>>> > > >>>>> I'm a little confused about this. So you're saying that we won't > > >>> include > > >>>>> release notes in the source artifact for the release? That seems > > >> pretty > > >>>>> atypical. > > >>>>> > > >>>>> Mike > > >>>>> > > >>>>> On Thu, Mar 3, 2016 at 11:34 PM, Jean-Daniel Cryans < > > >>> [email protected]> > > >>>>> wrote: > > >>>>> > > >>>>>> Yeah was planning on casually doing that. My gripe with release > > >> notes > > >>> is > > >>>>>> that they take time to write and review, delaying an RC by days if > > >> we > > >>>> were > > >>>>>> to wait for them to be written before releasing it. > > >>>>>> > > >>>>>> On Thu, Mar 3, 2016 at 1:22 PM, Todd Lipcon <[email protected]> > > >>> wrote: > > >>>>>> > > >>>>>>> Should we edit docs/release_notes.adoc to include release notes > > >> for > > >>>>>> 0.7.1 > > >>>>>>> before releasing? It seems odd that the release wouldn't mention > > >> the > > >>>>>> latest > > >>>>>>> version in the included release notes. > > >>>>>>> > > >>>>>>> -Todd > > >>>>>>> > > >>>>>>> On Wed, Mar 2, 2016 at 4:41 PM, Jean-Daniel Cryans < > > >>>> [email protected] > > >>>>>>> > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>>> Hi, > > >>>>>>>> > > >>>>>>>> We're happy to announce the first release candidate for Apache > > >>> Kudu > > >>>>>>>> (incubating) 0.7.1. > > >>>>>>>> > > >>>>>>>> This release fixes a few important bugs found during the process > > >>> of > > >>>>>>>> releasing 0.7.0 that didn't warrant sinking the vote for. It > > >> also > > >>>>>> takes > > >>>>>>>> care of fixing some licenses. > > >>>>>>>> > > >>>>>>>> The is a source-only release. The artifacts were staged here: > > >> https://dist.apache.org/repos/dist/dev/incubator/kudu/0.7.1-RC1/ > > >>>>>>>> > > >>>>>>>> It was built from this tag: > > >> > > > https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=bd191ec7366e13c3a11c6144f3b5af03d6496b38 > > >>>>>>>> > > >>>>>>>> The list of all issues fixed can be found here: > > >> > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20KUDU%20AND%20fixVersion%20%3D%200.7.1 > > >>>>>>>> > > >>>>>>>> KEYS file: > > >>>>>>>> http://www.apache.org/dist/incubator/kudu/KEYS > > >>>>>>>> > > >>>>>>>> I'd suggest going through the README, building Kudu, and running > > >>> the > > >>>>>> unit > > >>>>>>>> tests. > > >>>>>>>> > > >>>>>>>> Please try the release and vote; vote will be open for at least > > >> 72 > > >>>>>> hours. > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> > > >>>>>>>> J-D > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> -- > > >>>>>>> Todd Lipcon > > >>>>>>> Software Engineer, Cloudera > > >> > > >> > > >> > > >> -- > > >> Todd Lipcon > > >> Software Engineer, Cloudera > > >> > > >
