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
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
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
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
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
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.
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
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
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
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:
>
>
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,
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
> >
>
12 matches
Mail list logo
