Le samedi 24 août 2019, 23:55:22 CEST Enrico Olivelli a écrit :
> As I going to start the release procedure for Maven Core I have a bunch of
> I see that the procedure is slightly different from the procedure for
> plugins (), but actually the main differences are about the way we stage
> the release artifacts and the finalization phase, the core of the processs
> will be release:prepare and release:perform as usual.
you perfectly summarized the overall spirit
> So I will run "mvn:perform" and I will copy the artifacts to , that is
> in a directory named 3.6.2 (I see that Karl used 3.6.0 last time for 3.6.1,
> maybe it was a typo).
> I will run manually the integration tests against the binary artifacts
> generated and perform my self tests, if I have some problem can I drop the
> get tag and the staged repository or should I ban "3.6.2" tag forever and
> move immediately to 3.6.3 ?
regarding tags, the spirit is: if the tag went on public Git repo, you should
consider you can't delete (people may already have copied it)
> I see that Karl last time () sent a mail slightly different from the
> template  shall I use that email as template ?
this where you have a level of freedom...
> How does website staging works for Maven Core ? I see no specific
> instructions here in , I think the directory for Maven Core staging is
>  (According to the component-reference-documentation-helper tool).
> I have also found this script from Hervé, see , it runs the same
> commands as in the "common" procedure
exactly, nothing specific here
> Release notes:
> I can't find release notes for 3.6.0 and 3.6.1 on svn , have the sources
> been moved to another location ? on some git repo ?
you're mixing site markup source location with generated html location
Source is now in git: https://github.com/apache/maven-site/tree/master/ content/markdown/docs
Source in svn is the old read-only state from april 2018, when we swithced
site source from svn to git
> Should I prepare the release notes before then I cut the release and send
> the VOTE, or can I create them during the finalization of the release ?
> It will take time to write those notes, but I also think that writing the
> release notes helps a lot in understanding the effective contents of the
the release notes can be created after the vote starts: it's important for the
announce to users, not for the vote. What you can do is create the basic list
of issues for the vote, and propose voter to help on writing the analysis of
the release content: that's really an idea, not anything strictly required
> I have started a new build of master branch now, in order to perform a
> final check up, see.
> I am sorry if this list was so long but I feel it is a big responsibility
> to cut a release of Maven core and I want to be sure I am understanding
> clearly what I am doing.
it's great to see such serious handling of the job: don't worry, your summary
proves you perfectly understand important parts then won't break anything
during the review, I saw there is one task that is described nowhere:
publication of Core ITs run with the release https://maven.apache.org/core-its/ It's something I personally do sometimes but not every time, in general
without saying: I'll add a note in the release process, because it can be
useful to make that part as known as the rest of the release process (even if
it is less important)
> Please do not push changes to master branch and let me drive all of the
> commits until the release procedure is completed.
go, go, go