Denis, I agree with you.
Also I think that we should move to process which will require documentation updates during work on issue/feature and will part of code review process. Such approach has some useful benefits: - Documentation readiness at the same time when fix/implementation is ready (remember, documentation is part of a product). - Work on documentation and review could discover incompleteness of a fix or a feature on earlier stage (It is usual situation when some aspects were just forgotten, but documentation writing could spotlight such things). On Thu, Mar 12, 2020 at 7:49 PM Denis Magda <dma...@apache.org> wrote: > > Igniters, > > With the final 2.8 release steps checked out today by announcing the > version globally (congrats!), it's a proper time to consider and tweak our > release process, making completion of some phases more predictable and > aligned. I would like to dedicate this thread solely to changes related to > the documentation. > > If to do a recap, Ignite 2.8 announcement went out of sync with the > publication of binaries, Maven and other artifacts because our technical > documentation was completed long after the vote had been closed. > > We can easily eliminate such glitches for future releases if agree to start > a vote only if Ignite docs are ready and can be published the same day with > other release artifacts. If the docs are completed and available > internally while the vote goes then we can work on a release blog post > (referring to docs details) and announce the release the same day when the > binaries/docs availability. > > Thoughts? Let's change the process ensuring that the vote can be started > only if technical documentation is ready to be released? > > - > Denis
