[DISCUSS] Rethinking the release process

[Allen Wittenauer <aw...@apache.org>]

Hi.

	Currently we cut a branch and do all the release work in that branch.  While that was done to prevent work stoppage in the main branch while the release work is being done, it also has the side-effect that the release tags never show up in the main branch, making tools like git describe not work at all.  Given that I can think of only once in the history of the project where a commit went into main that didn’t end up in a release while the release process was ongoing…

	* Given the low rate of participation, does that protection these days, does that protection still make sense? 
	* What if the release process was changed such that all of the release work is (effectively) done in main?

	In my head:

		- release version gets updated in maven.config, etc
		- main is now effectively frozen for things that won’t end up in the release
		- release cycle:
			- release gets cut from a given sha
			a. if issues, PR -> main (and merge in any PRs that are hanging around?), re-cut from latest sha
			b. continue until approved
		- release sha is rel/ tagged
		- snapshot version gets updated in maven.config after tag


	IMHO, there is tremendous value in having release tags being marked in the main branch.  At some point (esp w/YETUS-1161 committed), we may very well be in a position to have the Apache Yetus version autodetermined by the value of the git tag, streamlining the release process even further.

	Thoughts?

Re: [DISCUSS] Rethinking the release process

[Nick Dimiduk <nd...@apache.org>]

I'm fine with your process as proposed. It'll be up to the release manager
to communicate "pencils down" and "work resumes" notifications to the dev
list, but I think that will be enough of a semaphore with this community.

+1

On Tue, May 3, 2022 at 5:57 PM Allen Wittenauer <aw...@apache.org> wrote:

>
> Hi.
>
>         Currently we cut a branch and do all the release work in that
> branch.  While that was done to prevent work stoppage in the main branch
> while the release work is being done, it also has the side-effect that the
> release tags never show up in the main branch, making tools like git
> describe not work at all.  Given that I can think of only once in the
> history of the project where a commit went into main that didn’t end up in
> a release while the release process was ongoing…
>
>         * Given the low rate of participation, does that protection these
> days, does that protection still make sense?
>         * What if the release process was changed such that all of the
> release work is (effectively) done in main?
>
>         In my head:
>
>                 - release version gets updated in maven.config, etc
>                 - main is now effectively frozen for things that won’t end
> up in the release
>                 - release cycle:
>                         - release gets cut from a given sha
>                         a. if issues, PR -> main (and merge in any PRs
> that are hanging around?), re-cut from latest sha
>                         b. continue until approved
>                 - release sha is rel/ tagged
>                 - snapshot version gets updated in maven.config after tag
>
>
>         IMHO, there is tremendous value in having release tags being
> marked in the main branch.  At some point (esp w/YETUS-1161 committed), we
> may very well be in a position to have the Apache Yetus version
> autodetermined by the value of the git tag, streamlining the release
> process even further.
>
>         Thoughts?