Le 03/10/2023 à 20:18, Bruno Kinoshita a écrit :
Same for me, I prefer to know ahead of time if there are any issues with
dependencies.
But the Commons components are mostly dependency-less, we are flooded by
dependabot requests to update non code related dependencies (Maven
plugins, GitHub a
Same for me, I prefer to know ahead of time if there are any issues with
dependencies.
On Tue, 3 Oct 2023, 19:23 Gary Gregory, wrote:
> Getting rid of this is good for dormant components ONLY IMO.
>
> It is definitely not a release time task for me. As an RM, I certainly
> don't want to spend ti
You could try archiving the projects. That way all jobs are disabled,
including dependabot. You can't push anymore, but unarchiving is just as
easy as archiving.
Rob
On 03/10/2023 19:22, Gary Gregory wrote:
Getting rid of this is good for dormant components ONLY IMO.
It is definitely not a
Getting rid of this is good for dormant components ONLY IMO.
It is definitely not a release time task for me. As an RM, I certainly
don't want to spend time doing this at release time. I want to update
dependencies as they become available to let them become part of the code
base where I can check
On Tue, 3 Oct 2023 at 15:47, Emmanuel Bourg wrote:
>
> Le 01/10/2023 à 14:09, sebb a écrit :
> > As the subject says: how does one stop dependabot and other analyses
> > from running on dormant components?
>
> +1
>
> And even on all components, updating the dependencies is a release time
> task. U
Le 01/10/2023 à 14:09, sebb a écrit :
As the subject says: how does one stop dependabot and other analyses
from running on dormant components?
+1
And even on all components, updating the dependencies is a release time
task. Updating 3 times the same Maven plugins between releases is a
waste
I've already made a start on that.
I'm replacing the entries with comments so people know where to defined them.
On Tue, 3 Oct 2023 at 12:44, Bruno Kinoshita wrote:
>
> Thank you Sebb and thank you Gary!
>
> On Tue, 3 Oct 2023 at 13:42, Gary Gregory wrote:
>
> > FYI, I'll do a pass over all pom
Thank you Sebb and thank you Gary!
On Tue, 3 Oct 2023 at 13:42, Gary Gregory wrote:
> FYI, I'll do a pass over all poms and remove those properties...
>
> Gary
>
> On Mon, Oct 2, 2023, 6:58 PM sebb wrote:
>
> > As the subject says, please do not use the pom to store RM details such
> as
> >
> >
FYI, I'll do a pass over all poms and remove those properties...
Gary
On Mon, Oct 2, 2023, 6:58 PM sebb wrote:
> As the subject says, please do not use the pom to store RM details such as
>
> commons.releaseManagerName
> commons.releaseManagerKey
>
> These properties are personal to the user, a
On Tue, 3 Oct 2023 at 09:48, Bruno Kinoshita wrote:
>
> I recall seeing these properties in the commons-release-plugin docs I use
> as reference whenever I need to release a component (which the last time
> was a long time ago, sorry).
>
> The commons-release-plugin links to this page:
>
> https:/
I recall seeing these properties in the commons-release-plugin docs I use
as reference whenever I need to release a component (which the last time
was a long time ago, sorry).
The commons-release-plugin links to this page:
https://commons.apache.org/releases/prepare.html
Maybe we need to update
The properties are used by the release plugin.
But since they are unique to the user, they do not belong in the shared pom.
On Tue, 3 Oct 2023 at 02:33, Phil Steitz wrote:
>
> +1 but why then are those properties there?
>
> Phil
>
> > On Oct 2, 2023, at 3:58 PM, sebb wrote:
> >
> > As the subj
12 matches
Mail list logo
