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?
