jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <p.moua...@ubik-ingenierie.com>
Subject Re: JMeter releases vs manual steps
Date Tue, 12 Mar 2019 07:34:34 GMT
Great proposals

On Monday, March 11, 2019, Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
wrote:

> 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
>


-- 


[image: logo Ubik Ingenierie] <https://www.ubik-ingenierie.com> Philippe
Mouawad
Senior Performance Expert
320914981 <+33320914981> | p.mouawad@ubik-ingenierie.com
[image: ubik-ingenierie.com] ubik-ingenierie.com
<https://www.ubik-ingenierie.com> | [image: 03.20.91.49.81] 03.20.91.49.81
<+33320914981> | [image: 23 rue du chemin de fer , 59100 , Roubaix] 23 rue
du chemin de fer, 59100, Roubaix
<https://www.openstreetmap.org/#map=18/50.69454/3.16455>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message