commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: Git status update
Date Mon, 09 Sep 2019 13:00:17 GMT
It seems like we really should put future release tags under 'rel/'

It's too bad it can't simply be 'releases/' to make it clearer.

Then there is the issue of moving all of our past release tags under
'rel/', another thing we should do...


On Fri, Sep 6, 2019 at 5:02 AM sebb <> wrote:

> [This was sent to private@commons, but does not seem to have been
> forwarded to the dev@ list.]
> Please note the penultimate paragraph about tagging successful
> releases under rel/
> AFAICT, we have not been doing that, so our release tags are not
> automatically protected against deletion.
> We should probably start doing this going forward.
> Note that the rel/ tags cannot be deleted, so this needs to be done
> very carefully.
> I think the only change we need to make to the release process is to
> add a new step at the end to create the rel/tag from the commit SHA.
> 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.
> Thoughts?
> S.
> ---------- Forwarded message ---------
> From: David Nalley <>
> Date: Sun, 10 Jan 2016 at 18:00
> Subject: Git status update
> To: <>
> Greeting PMCs:
> (bcc to
> Following direction from the Board, Infrastructure has modified git to
> permit force pushes, and branch/tag deletion.
> In accordance with the guidance that the Board we've implemented a few
> changes you should be aware of:
> First, If a forced commit is pushed, the subsequent commit email will
> contain '[Forced Update!]' in the subject line. The hope here is that
> it draws extra attention to the situation for a project community to
> be aware, and take appropriate action if needed.
> Second, we've changed the 'protected' portions of git to primarily
> focus on refs/tags/rel - thus any tags under rel, will have their
> entire commit history. This provides the provenance that the ASF needs
> for releases, while still giving projects the ability to mold their
> repository in the way they see fit.
> Thus when a release vote is successful - 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.)
> If you have questions, please feel free to email
> --David
> on behalf of Apache Infrastructure
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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