Hi,

I see https://wiki.apache.org/jmeter/ReleaseCreation lists current release
dance, and I have a couple of questions/ideas.
I wonder what is the minimal number of manual steps required to do a
release assuming "current source repository passes tests and looks good".

What if we had the following (imaginary commands):
1) ./prepare_release_candidate. It checks out the source to a temporary
folder, runs tests, builds artifacts, prints "vote" draft, and uploads the
artifacts to dist.apache.org/dev, stages maven artifacts, pushes site
preview somewhere.

2) ./verify_candidate (e.g. to be used by the voting participants). It
downloads artifacts, verifies checksums, signatures, and it could
optionally build the same artifacts locally to verify if the resulting SHA
match or not.

3) ./promote_release. It releases Nexus repository, releases dist.apache.org
artifacts, pushes site, prepares "announce" draft.

So far the script does not really need to add commits. There's "doap file",
however I guess we could just move it to the regular site build, so it is
autogenerated.

Gradle can use different "actual version" based on command line flags. In
other words, it can release exactly the same commit as a snapshot build, as
a release candidate, and as a release.
Of course the produced binary artifacts would be different (for instance
jar files include Version attrbute which will be different), however the
source artifacts could easily be the same.

Then we don't really need to have those dummy "update version to release",
"update version to next", "oh, rollback", etc kind of commits.
We just don't commit (don't alter the source) during the release and that's
it.

Of course, after the release is made we should increment version, and
that's a commit. It could be a part of "promote_release" or a manual
action. I'm not sure yet.

Am I missing something?
Are there important steps which must be split into individual commands?
Current ReleaseCreation has quite a few of manual actions here and there
(string replacements, commands, etc), and I think we don't really *want* to
have those.

Vladimir

Reply via email to