jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject Re: Git status update
Date Tue, 01 Oct 2019 13:58:53 GMT
>part of the release process
>should become tagging the voted upon commit SHA under rel/ to make it
>indelible. ('# git tag rel/v15.4.2 ' or something similar.)

We have "publishRelase" Gradle task that creates "release tag" and moves
the release from dev to release area on
We could teach it to create rel/v5.2.0 tag as well.

So the question is: should we create both "v5.2.0 and rel/v5.2.0" tags?
Should we create just "rel/v5.2.0"?
Even though I don't like "rel/v5.2.0" naming for the release tag, it
becomes mandatory, so plain v5.2.0 will be excessive.

>We should be very careful about changing anything in the POM, lest it
>causes the rel/tag to be created before the RC has been approved.

Technically speaking, we never edit POM files directly.
JMeter-generated POM files do not contain tag/branch information.

Here's how current POM files look like:

>Following direction from the Board, Infrastructure has modified git to
>permit force pushes, and branch/tag deletion

This is super great news. +100500.
Now we can force-push small changes. What a time.
For instance:
be just a single commit instead of two separate ones.

Just in case, I suggest to use push --force-with-lease rather than simple

>It looks like JMeter Git may have been set up to protect all tags.

My recent conversation with Infra re Git cleanup and the removal of the
stale jars concluded that
Infra validates **no** Git tags.
They validated branches only.

I've removed v5.2.0_RC1 from Git today and it went just fine.

However, the mail refers to refs/tags/rel, which indeed means "tags", so
the current protection seems to be related to rel/* tags only.


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