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 <janard...@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 >
