[DISCUSS] Generating documentation multiple times during RC generation

[Janardhan <ja...@apache.org>]

Hi all,

While making the release artifacts off the commit, all the files are
supposed to be with
that same version. If it is 2.1.0-rc1, then that version will be in
pom.xml, python, docs.

At the moment, we have generated files in html format with version number
in every file.
So, passing in as a variable is not possible.

The release process would add noise (like +2k line every rc) to the
development (master) branch.

For this reason, we could use a different branch till a release candidate
is finalized. The
flow diagram [1]. This is generally done elsewhere.

But any ideas about how to work around this limitation. The info above is
to my understanding, please
correct where possible.

[1]
https://raw.githubusercontent.com/j143/release-scripts/e9173593047cfe5dbb915ec73a0cf26d4fd106fc/git-flow-1.svg

Thank you,
Janardhan

Re: [DISCUSS] Generating documentation multiple times during RC generation

[arnab phani <ph...@gmail.com>]

While I agree with the fact that the master branch grows between release
candidates, I don't consider that as a problem given the moderate
frequency of commits.
The in-progress features will be marked as under development in release
notes anyway, and we will hold the bigger features (if any) to be merged.
Maintaining another branch adds complexity to the release process, such as
fixing the release scripts.
However, a release branch might be useful for a major release as the
process may take longer (a higher #RCs).

Regards,
Arnab..

On Wed, Jun 2, 2021 at 6:26 PM Janardhan <ja...@apache.org> wrote:

> Hi all,
>
> While making the release artifacts off the commit, all the files are
> supposed to be with
> that same version. If it is 2.1.0-rc1, then that version will be in
> pom.xml, python, docs.
>
> At the moment, we have generated files in html format with version number
> in every file.
> So, passing in as a variable is not possible.
>
> The release process would add noise (like +2k line every rc) to the
> development (master) branch.
>
> For this reason, we could use a different branch till a release candidate
> is finalized. The
> flow diagram [1]. This is generally done elsewhere.
>
> But any ideas about how to work around this limitation. The info above is
> to my understanding, please
> correct where possible.
>
> [1]
>
> https://raw.githubusercontent.com/j143/release-scripts/e9173593047cfe5dbb915ec73a0cf26d4fd106fc/git-flow-1.svg
>
> Thank you,
> Janardhan
>