Hi Dale,
that’s unfortunate that you had that many problems … I have to admit that the
branch operation directly pushes was new to me … the prepare operation
shouldn’t and the perform should only checkout. BUT I do know that for all the
data in the scm management block of the pom is important.
It was changed via [1]. Presumably now when a pull request is created it will
default to “develop” as the destination.
The insights page on GitHub now reports more useful commit info for
“Contributors”.
> [1] https://issues.apache.org/jira/browse/INFRA-15780
>
Hmm…
per the releasing.adoc, I ran the release:branch step in a new clone of the
GitHub mirror repo (I neglected to clone the ASF repo) and it actually
auto-pushed 3 items to the ASF repo :-((when release:branch completed,
there were still two commits pending/not-yet-pushed as expected)
Hi Dale,
I think I did write down all the steps involving Maven in the document:
src/site/asciidoc/releasing.adoc
The merge with the other RM doc is that the release-perform will create the
source tar/zip we vote on in “target/checkout/target/***.tar.gz” and the
corresponding zip. The files
Hi Chris,
At a high level, we need to ensure someone can reproduce what you just went
through for 1.2.0.
It feels like I should try going through the process for a, fictitious at the
moment, 1.3.0 release. i.e., going all the way up to staging the release in
dist.apache.org and in Nexus
Thanks. I’ve created the 1.2.0 and 1.3.0 releases on Jira and updated the
issues (assigned fixed-in versions, transitioned many to “closed”).
Per the RM-guide (and apache policy) I also removed the superseded
1.1.0-incubating from dist.apache.org.
> On Jan 2, 2018, at 12:02 PM, Christofer Dutz
