Great I pushed tags where the situation was clear.
I chose not to push maven-compiler-plugin-2.0.1, since it causes more trouble than this minor version (from 2006, between 2.0 and 2.0.2) is worth Same for maven-shade-plugin-1.0 I still need to work on maven-assembly-plugin, maven-dependency-plugin and maven-site-plugin: this last one is tricky because we had parallel branches for 2.x and 3.x... IMHO, the quality of the tags os now good enough: we know that absolute reference is svn, but the git mirror has sufficient details This WE, I'll do the same work on shared components and skins. thank you for your help Hervé Le mardi 2 janvier 2018, 14:32:00 CET Plamen Totev a écrit : > Hi, > > > On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <herve.bout...@free.fr> > > wrote: thank you Plamen: this script is really awesome! > > You're welcome. I'm glad it helped. > > > And I just pushed the result on maven-acr-plugin: you can see the result > > live. As you can see, the tags on GitBox [2] are updated but not the tags > > on GitHub [3] even if I tried to force to GitHub (and it looked ok) > > I don't know if it's a major issue > > Would you check again. To me it looks like as if now the tags on > GitHub are updated as well. > > > The rework of tags is ok for 420 tags on plugins, and fails for 31: > > - 16 tags don't point to a release plugin commit [4] > > The script tries to find the "[maven-release-plugin] prepare release" > commit reachable from the master branch and if it does not find it > then it says that the commit is not made with the release plugin. > Looks like there a couple of such cases (at least the commit message > is different). They are: > > * maven-checkstyle-plugin-2.11 - the "copy for tag" commit is with > revision 1540890. The previous commit 1540889 is with message "foo" > (literally), but if you examine the content you'll see that this is > the commit that does the release. So I think it's safe to tag it - its > SHA in the split repository is > 8f09be0a11e9761cceca127f4f8dcd439dcc561e[1]. > * maven-dependency-plugin-2.0-alpha-2 - the "copy for tag" commit is > with revision 517496. The previous commit 517495 is with message > "rollback plexus-utils to 1.1 to avoid conflicts with m2.0.6", but > again if you examine the content you'll see that this is the commit > that does the release. Its SHA in the split repository is > 9af772788381f5b79081a649748b2d8137782895[2]. > * maven-help-plugin-2.0.1 - looks like the release is > 2f95a7ecb720f95c1cbde1a52b3360964be29e72[3]. The commit message is > "[maven-release-plugin] prepare release maven-help-plugin-2.0" but if > you check the pom version you'll see it is 2.0.1 > * maven-project-info-reports-plugin-mvn%20release%3Aprepare - Actually > there is a "prepare release" > commit(9de1aa37f0d38547aea80eac1abfe2078c2220c1[4]) but it is not > found by the script because of the escape characters in the tag name. > Actually I don't think this tag is needed as it seems to point to a > release attempt gone wrong. > > Another possible cause is that there is "prepare release" commit but > it's not reachable from master. Looks like some of the plugins have > been released from branch and those commits are not part of the master > branch. Here is a list with such releases: > > * maven-assembly-plugin-2.2-beta-4 is released from branch > maven-assembly-plugin-2.2-beta-4 > * maven-assembly-plugin-2.6 is released from branch > maven-assembly-plugin-2.x * maven-compiler-plugin-2.0.1 is released from > branch > maven-compiler-plugin-2.0.x > * maven-site-plugin-2.4 is released from maven-site-plugin-2.x > * maven-site-plugin-3.0-beta-1, maven-site-plugin-3.0-beta-2, > maven-site-plugin-3.0-beta-3 are released from maven-site-plugin-3.x > > The branches are not preserved in the split repositories(but they do > exist in maven-plugins). I guess we should migrate them as well or I'm > wrong? Do you think it will be an issue to have branches after the > migration that are not merged into master? Migrating the branches into > the split repositories should not be complicated (I think) but haven't > tried yet. I may try to migrate maven-site-plugin-3.x for example to > see how it is in reality. > > Also it appears that some of the plugins were part of "sandbox" and > this part of their history is not preserved after the split (I'm not > sure how much of it is part of maven-plugins. Keeping this part of the > history may prove to be more difficult. > > * maven-shade-plugin-1.0-alpha-13, maven-shade-plugin-1.0-alpha-14 and > maven-shade-plugin-1.0-alpha-15 were released when the Shade plugin > was in the > sandbox(https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-> > shade-plugin). > > I have no idea about the cause for > maven-dependency-plugin-2.0-alpha-1-RC2 and > maven-site-plugin-pre-compat-with-doxia-1.0-alpha-7 tags. > > > - 15 tags have an issue I don't really understand yet [5] > > I haven't looked at them yet, but in general the error means that a > "prepare release" commit reachable from master is found but the > content of the files (the SHA of the root tree) does not match the > tagged ones. I suspect that the cause may be that there are a multiple > attempts on release and the last one does not match the tagged(for > example the first one is tagged). > > Regards, > Plamen Totev > > [1] > https://github.com/apache/maven-checkstyle-plugin/commit/8f09be0a11e9761cce > ca127f4f8dcd439dcc561e [2] > https://github.com/apache/maven-dependency-plugin/commit/9af772788381f5b790 > 81a649748b2d8137782895 [3] > https://github.com/apache/maven-help-plugin/commit/2f95a7ecb720f95c1cbde1a5 > 2b3360964be29e72 [4] > https://github.com/apache/maven-project-info-reports-plugin/commit/9de1aa37 > f0d38547aea80eac1abfe2078c2220c1 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
