Great job!
while we are here and changing format to something more compact.
I wonder if we could remove those extra (useless?) spaces such:
providers.add( requireNonNull( service, "service instance cannot be null" ) );
On Sat, 15 Oct 2022 at 17:50, Guillaume Nodet wrote:
>
> Le ven. 14 oct.
I've also deployed the distributions at
https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-2/binaries/
https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-2/sources/
and the web site at:
http://svn.apache.org/repos/asf/maven/website/components/ref/4-LATEST/index.html
On Sun, Oct 16, 2022 at 8:24 AM Guillaume Nodet wrote:
>
> Le sam. 15 oct. 2022 à 14:20, Slawomir Jaranowski
> a écrit :
>
> > For failed release I would prefer
> > - revert commits if needed - we will have history
> > - remove tag
> > try again :-)
> >
> > If we bump versions only caused by
Thanks.
Site is also available under https://maven.apache.org/ref/4-LATEST/
- there are some missing links like
https://maven.apache.org/ref/4-LATEST/maven-model/maven.html
- some are outdated like
https://maven.apache.org/ref/4-LATEST/maven-settings/settings.html
For me it can be fixed in next
+1
as defined in our release process for core
https://maven.apache.org/developers/release/maven-core-release.html
I replaced md5 and sha1 with sha512 in
https://maven.apache.org/developers/release/maven-core-release.html
build is not fully reproducible: reference was done on *nix with JDK 8,
Le sam. 15 oct. 2022 à 14:20, Slawomir Jaranowski
a écrit :
> For failed release I would prefer
> - revert commits if needed - we will have history
> - remove tag
> try again :-)
>
> If we bump versions only caused by technical problems during release we
> need to change / create labels in jira,
>
> Fully agreed, that's what I initially tried to do. But the repository does
> not allow removing a tag. So this would have to be changed.
>
I see deleted tags ... maybe Maven core repository has another
configurations
Hi,
We solved 17 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12352066
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20resolution%20%3D%20Unresolved
Staging repo:
+1, BUT in addition to Hervé's answer:
Create a file '.git-blame-ignore-revs', which seems to be a common convention:
https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame
This way, we can see CODE changes via diff/blame without those nasty
formatting changes.
---
For the
Le dim. 16 oct. 2022 à 10:11, Hervé Boutemy a
écrit :
> key prerequisite is to make sure we don't screw history with the big
> reformat
> commits: I absolutely need to keep git blame provide useful feedback.
>
Right, good point.
> it seems git blame --ignore-revs in Git 2.23 does what we
key prerequisite is to make sure we don't screw history with the big reformat
commits: I absolutely need to keep git blame provide useful feedback.
it seems git blame --ignore-revs in Git 2.23 does what we need:
https://michaelheap.com/git-ignore-rev/
Does anybody have experience with this and
only one concern: clarify our convention for the initial reformat of any Git
repository so that it works with git blame --ignore-revs
(I hope current tools support for this feature is good enough nowadays)
Regards,
Hervé
Le vendredi 14 octobre 2022, 10:41:30 CEST Guillaume Nodet a écrit :
> So
12 matches
Mail list logo
