Le 2024-08-09 à 17 h 01, Tamás Cservenák a écrit :
Resolver 1.9.22 and 2.0.1 are out, next are upcoming Maven releases...
please keep eye and review PRs (for both, if possible)
If it includes Maven 4, can we call it "beta" again?
Howdy,
Resolver 1.9.22 and 2.0.1 are out, next are upcoming Maven releases...
please keep eye and review PRs (for both, if possible)
Thanks
T
On Fri, Aug 2, 2024 at 11:29 AM Tamás Cservenák wrote:
> Howdy,
>
> just a heads up: we have some nice resolver (memory consumption)
>
Howdy,
just a heads up: we have some nice resolver (memory consumption)
improvements that will probably yield Resolver 1.x/2.x releases soon (2.x
has much more aside of these above):
1.x:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.22
2.x
Hi all,
as already mentioned, I will create a mail thread for each epic that we defined
for the “Support & Care for Apache Maven” initiative.
All information about this epic can be found at
https://github.com/OpenElements/maven-support-care/issues/41
For the submission, we needed to create sep
I'm also planning to release
* maven-filtering 2.3.2
the following PRs would need review:
https://github.com/apache/maven-filtering/milestone/1
remaining issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20component%20%3D%20maven-filtering%20AND%20stat
Thanks. This is helpful.
On Sat, Feb 24, 2024 at 1:44 PM Slawomir Jaranowski
wrote:
>
> Hi,
>
> I'm going to release at the end of next week:
>
> 1. maven-assembly-plugin
>
> issues for next release:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317220%20AND%20fixVersion%20%3D%20
Hi,
I'm going to release at the end of next week:
1. maven-assembly-plugin
issues for next release:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317220%20AND%20fixVersion%20%3D%2012353243%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC
open issues: https://issues.apache.org/jira/pr
I don't care about the threads. They are fine with me. I care about the
amount of ceremony that you create that eats into developer time. If you
want to do it for yourself: feel free to do so. It is your time after all.
But you and others then turn around and say "everyone now needs to do what
I a
Henning,
This intent of all threads (the "[HEADS UP]") that I have been creating
since the 3.9.0 release was actually meant as a communication effort to
users not on ML (btw, see related comm related discussions). What I usually
do is copy the ponymail URL of the thread and post it on twitter or
m
Hi,
With validation=summary when only EXTERNAL issue are presents we have:
[WARNING]
[WARNING] Plugin [INTERNAL] validation issues were detected in following
plugin(s)
[WARNING]
[WARNING]
[WARNING] For more or less details, use 'maven.plugin.validation' property
with one of the values (case insen
Well the problem is that most users won't notice any "votes" or are able
to take action on it (e.g. because they can't run a custom build maven
on their CI easily).
I already have recommended that there should be a SNAPSHOT build on the
download-page with clear indication to the user to help t
Le lun. 29 mai 2023 à 09:03, Delany a écrit :
> Since most issues (like this one) are discovered after release, what about
> introducing a backward compatibility policy of "second-to-last"?
> For example, a feature is introduced (with config value BRIEF) in 3.9.2
> Then its decided in 3.9.3 to ch
Since most issues (like this one) are discovered after release, what about
introducing a backward compatibility policy of "second-to-last"?
For example, a feature is introduced (with config value BRIEF) in 3.9.2
Then its decided in 3.9.3 to change it to something else (SUMMARY).
This should be allo
You spend so much time on ceremony and bureaucracy by filing tickets that
no one is going to pick up or read and then creating pull requests that at
best will be glanced at and then "LGTM"ed.
This is a trivial, non-controversial change that any committer can just
commit. Worst case scenario, someo
Draft:
https://github.com/apache/maven-site/pull/424
T
On Fri, May 26, 2023, 22:23 Tamás Cservenák wrote:
> Howdy,
>
> good call, created https://issues.apache.org/jira/browse/MNG-7797
>
> Thanks
> T
>
> On Fri, May 26, 2023 at 10:09 PM Henning Schmiedehausen <
> henn...@schmiedehausen.org> wro
Howdy,
good call, created https://issues.apache.org/jira/browse/MNG-7797
Thanks
T
On Fri, May 26, 2023 at 10:09 PM Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:
> maven 3.9.2:
>
> mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> install
> [...]
>
> current 3
maven 3.9.2:
mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
install
[...]
current 3.9.3-SNAPSHOT:
mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
install
[...]
*[WARNING] Invalid value specified for property maven.plugin.validation:
'BRIEF'. Supporte
Hi Tamas,
I'm still getting locking issues with maven-surefire-plugin:3.1.0
I assumed these were resolved in
https://issues.apache.org/jira/browse/MRESOLVER-346 which i believe made it
into Maven 3.9.2, so switched back to Maven 3.9.0
What was the previous default value of aether.syncContext.name
Howdy,
Resolver 1.9.11 is shaping:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.11
one resolver issue under scrutiny:
https://issues.apache.org/jira/browse/MRESOLVER-362
Maven 3.9.3 as well:
https://issues.apache.org/jira/issues/?jql=project
t mandatory but let's be honest in real life everybody
> does it :)
> At the end, if release drafter is configured it's just one click, and
> if not it's 2 clicks or one command line if using github cli tool gh
>
>
I did an experiment for Plugin Tools -
https://github.com/a
; >> > > of sub projects (maintained by different people who are not
> >> > > maintaining every project) and we can be happy having few people
> >> > > maintaining those during their spare time. So not sure it's a very
> >> > > good id
e
>> > > maintaining those during their spare time. So not sure it's a very
>> > > good idea to have too strict policies/procedures especially when it
>> > > comes to adding a nice to have cherry on the top for users
>> > > Especially when the rest of
rocedure has been done.
> > >
> > >
> > >
> > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > > wrote:
> > > >
> > > > Hi,
> > > > I start a discussion ... as beginning - s
On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski
> > wrote:
> > >
> > > Hi,
> > > I start a discussion ... as beginning - some my loose thoughts
> > >
> > > We use Jira (for most of) as our primary issues management system.
> > > We manage
>
> > We use Jira (for most of) as our primary issues management system.
> > We manage release notes in Jira - it is the source for announcements.
> >
> > In some projects we have GitHub releases notes.
> > In some cases we use release-drafter for preparing GitHub r
ent system.
> We manage release notes in Jira - it is the source for announcements.
>
> In some projects we have GitHub releases notes.
> In some cases we use release-drafter for preparing GitHub releases notes.
> Some of release notes on GH - it is not actual
>
> Challenge:
Hi,
I start a discussion ... as beginning - some my loose thoughts
We use Jira (for most of) as our primary issues management system.
We manage release notes in Jira - it is the source for announcements.
In some projects we have GitHub releases notes.
In some cases we use release-drafter for
more manual
works for all releases
- dropping / moving tag in repository can have impact on fetched local
repositories - and can generate more questions
Users in most cases don't look at repository level.
Versions aren't incremental numbers so it is not important that some of
them
Leads to the question: what is the most common source for end users.
Without debate it is not git so burning versions should be on central only
IMHO. For git we have clean solutions to not burn anything so it sounds
worth using them IMHO.
Le mar. 1 nov. 2022 à 13:56, Heiko Studt a écrit :
> Hell
Hello,
Am 31.10.22 um 08:45 schrieb Slawomir Jaranowski:
We are talking about a situation which happens very rarely - canceling a
vote.
In such a case simply delete tag and create next with next release run with
the same label is easy and possible.
If your GIT repository has fetched some t
Hmm, so you mean we should primite not existing releases (for users and
asf) as being actual partial releases?
Not sure which sense it makes from my window when we have all we need to
not create these ambiguitues.
If release process is too heavy we can automate most of it already - we
just never
Am 2022-10-31 um 08:45 schrieb Slawomir Jaranowski:
Hi,
We are talking about a situation which happens very rarely - canceling a
vote.
Adding the next manual step like post process tagging only for one reason
is not justified.
I think that when we have multiple release labels for issues and on
and local clone).
> > > > The tag is not needed as we are supposed to vote sources tarball.
> > > > This even make the release process faster as you avoid some extra
> > network
> > > > operations such another clone..
> > > > If really asking by someone
don’t push and local clone).
> > > The tag is not needed as we are supposed to vote sources tarball.
> > > This even make the release process faster as you avoid some extra
> network
> > > operations such another clone..
> > > If really asking by someone the tag ca
in a fork
> >
> > On Mon, 31 Oct 2022 at 6:32 am, Guillaume Nodet
> wrote:
> > > I don't see the point of burning releases. Imho, this has a negative
> > > impact on users for no benefits.
> > > If the problem is just about not rewriting the git hist
ing by someone the tag can be pushed in a fork
>
> On Mon, 31 Oct 2022 at 6:32 am, Guillaume Nodet wrote:
> > I don't see the point of burning releases. Imho, this has a negative
> > impact on users for no benefits.
> > If the problem is just about not rewriting the
, Guillaume Nodet wrote:
>
> > I don't see the point of burning releases. Imho, this has a negative
> > impact on users for no benefits.
> > If the problem is just about not rewriting the git history, we could
> simply
> > tag manually once the vote has succeeded
clone..
If really asking by someone the tag can be pushed in a fork
On Mon, 31 Oct 2022 at 6:32 am, Guillaume Nodet wrote:
> I don't see the point of burning releases. Imho, this has a negative
> impact on users for no benefits.
> If the problem is just about not rewriting the g
I don't see the point of burning releases. Imho, this has a negative
impact on users for no benefits.
If the problem is just about not rewriting the git history, we could simply
tag manually once the vote has succeeded (or find a way to delay pushing
the tag even if the tag has been creat
Am 2022-10-30 um 20:32 schrieb Elliotte Rusty Harold:
On Sun, Oct 30, 2022 at 6:53 PM Michael Osipov wrote:
Am 2022-10-30 um 19:39 schrieb Elliotte Rusty Harold:
IMO A failed release should not burn an external facing version
number. If it does, then the release process is flawed and needs to
On Sun, Oct 30, 2022 at 6:53 PM Michael Osipov wrote:
>
> Am 2022-10-30 um 19:39 schrieb Elliotte Rusty Harold:
> > IMO A failed release should not burn an external facing version
> > number. If it does, then the release process is flawed and needs to be
> > fixed.
>
> Why? This I don't understand
Am 2022-10-30 um 19:39 schrieb Elliotte Rusty Harold:
IMO A failed release should not burn an external facing version
number. If it does, then the release process is flawed and needs to be
fixed.
Why? This I don't understand. From ASF PoV only the source release ZIP
file is relevant. Everythin
11:05 AM Slawomir Jaranowski
> wrote:
> >
> > Hi,
> >
> > Current procedure of releases is unclear in case of restart releases. [1]
> >
> > I see two cases:
> >
> > - technical problem during release ... something goes wrong after SMC tag
> >
IMO A failed release should not burn an external facing version
number. If it does, then the release process is flawed and needs to be
fixed.
On Sun, Oct 30, 2022 at 11:05 AM Slawomir Jaranowski
wrote:
>
> Hi,
>
> Current procedure of releases is unclear in case of restart release
Am 2022-10-30 um 12:04 schrieb Slawomir Jaranowski:
Hi,
Current procedure of releases is unclear in case of restart releases. [1]
I see two cases:
- technical problem during release ... something goes wrong after SMC tag
was created
- canceled vote
Technically we have many solutions:
1
Hi,
Current procedure of releases is unclear in case of restart releases. [1]
I see two cases:
- technical problem during release ... something goes wrong after SMC tag
was created
- canceled vote
Technically we have many solutions:
1.
- drop old tag and restart with the same version
- no
Acknowlegded, but ASM 9.1 already supports Java 17, which is our main
target.
Robert
-- Origineel bericht --
Van: "Gary Gregory"
Aan: "Maven Developers List" ;
mthmuld...@apache.org
Verzonden: 18-8-2021 13:34:05
Onderwerp: Re: JDK 17 related plugin releases
N
se those plugins
> >> that depend on ASM.[1]
> >> Even though optional, I'll release both the maven-compiler-plugin and
> >> maven-javadoc-plugin too.
> >> I could use some help with the other plugins too, including verifying
> >> if there are PRs worth
pearing soon we should at least release those plugins
that depend on ASM.[1]
Even though optional, I'll release both the maven-compiler-plugin and
maven-javadoc-plugin too.
I could use some help with the other plugins too, including verifying
if there are PRs worth adding and the doing the rel
o.
I could use some help with the other plugins too, including verifying if there
are PRs worth adding and the doing the releases.
Please raise your hand so we can divide the work.
thanks,
Robert
[1] https://cwiki.apache.org/confluence/display/MAVEN/ASM+dependin
d the doing the releases.
Please raise your hand so we can divide the work.
thanks,
Robert
[1] https://cwiki.apache.org/confluence/display/MAVEN/ASM+depending+projects
question will give a hint on what to do with the parent POM (which is
one of the reasons I stopped pushing to Central half-baked releases)
The second question is less trivial than it looks like: we can now create Git
repositories starting with "maven-" only.
Regards,
Hervé
How am I then supposed to solve MASFRES-31?
Release Parent 35 w/o dropping staging repos?
M
Am 2020-04-22 um 19:04 schrieb Hervé BOUTEMY:
if that your point of interest, I can explain because I did last releases of
parent POMs
as you can see, apache-resource-bundles is in org.apache.apache
if that your point of interest, I can explain because I did last releases of
parent POMs
as you can see, apache-resource-bundles is in org.apache.apache, unlike every
other Maven parent POMs that are in org.apache.maven
Then during staging, they go in a separate staging area.
And given nobody
Merci Hervé, I was actually referring to the Central deployment. Nothing
in (5,30) and (30,) has been deploy to Central, but the rest of the
reactor is in Central. This looks wrong to me.
See:
https://repo.maven.apache.org/maven2/org/apache/apache/resources/apache-resource-bundles/
Michael
everything is documented in the Git migration Wiki page [1]
gives a link to the documentation for the bundles themselves [2]
and if you look at our full sources descriptor [3]
you'll see corresponding line:
pointing to the git2svn mirror [4]
Regards,
Hervé
[1] https://cwiki.apache.org/confluenc
Folks, apache-resource-bundles is released with maven-parent and tagged
[1], but where is it?
Not here:
https://repo.maven.apache.org/maven2/org/apache/apache/resources/apache-resource-bundles/
Source release [2] contains the POM...
Ideas? INFRA?
[1]
https://github.com/apache/maven-parent/bl
investigation showed us that in most cases API producers do not migrate
their APIs to newer Java Releases. Despite this, the API remains to be widely
used by consumers on GitHub. Can you provide us with more information on this
phenomenon?
Did you and your team ever discuss the migration to new
rsions and their features.
Our investigation showed us that in most cases API producers do not
migrate their APIs to newer Java Releases. Despite this, the API remains
to be widely used by consumers on GitHub. Can you provide us with more
information on this phenomenon?
Did you and your team e
would like to better understand
as to why these APIs do not support newer Java language versions and their
features.
Our investigation showed us that in most cases API producers do not migrate
their APIs to newer Java Releases. Despite this, the API remains to be widely
used by consumers on GitHub
I see no one objects.
I will cut a release for jdeps as soon as possible.
for the 'scripting' plugin maybe I will need more help than usual as it is
the first release of ever.
Thanks
Enrico
Il giorno mar 28 mag 2019 alle ore 14:11 Enrico Olivelli <
eolive...@gmail.com> ha scritto:
> Hi,
> I wo
Hi,
I would like to cut a release of JDeps plugin soon.
I have committed a fix for an annoying problem with MultiRelease Jars (1)
It is time to cut a first release of Maven Scripting Plugin.
Thoughts ?
Enrico
[1] https://issues.apache.org/jira/browse/MJDEPS-23
Hi all,
Just wanted to give you a heads up about the recent Maven wrapper and plugin
releases.
https://www.simpligility.com/2019/03/recent-maven-wrapper-updates/
Some pretty nice features worth checking out imho.
Go update your projects to this latest version!
Manfred
Hi to all,
I would like to start a first 3.0.0-alpha-1 release of the Maven JLink
Plugin[1] and the Maven JMod Plugin[2] to support creation of Java Run
Time Images for Java 9...
Are there any ideas/suggestions/improvements before the first public
release of them?
JIRA projects do already
Hi Karl Heinz,
regarding both install/deploy plugin in combination with
artifact-transfer: we should somehow make this a 2-phase strategy in the
future: first phase upload pom, main artifact and attached artifacts (in
parallel when possible), second phase download + upload metadata files. I
Hi Michael,
On 07/05/17 18:31, Michael Osipov wrote:
Am 2017-05-07 um 17:34 schrieb Karl Heinz Marbaise:
Hi Michael,
On 07/05/17 17:23, Michael Osipov wrote:
Am 2017-05-07 um 15:55 schrieb Karl Heinz Marbaise:
Hi to all,
after maven-artifact-transfer 0.9.1 is done
I will go forward to make
Am 2017-05-07 um 17:34 schrieb Karl Heinz Marbaise:
Hi Michael,
On 07/05/17 17:23, Michael Osipov wrote:
Am 2017-05-07 um 15:55 schrieb Karl Heinz Marbaise:
Hi to all,
after maven-artifact-transfer 0.9.1 is done
I will go forward to make a release of:
maven-dependency-plugin 3.0.1 which con
Hi Michael,
On 07/05/17 17:23, Michael Osipov wrote:
Am 2017-05-07 um 15:55 schrieb Karl Heinz Marbaise:
Hi to all,
after maven-artifact-transfer 0.9.1 is done
I will go forward to make a release of:
maven-dependency-plugin 3.0.1 which contains a Java 8 fix
and afterwards I will go further t
Am 2017-05-07 um 15:55 schrieb Karl Heinz Marbaise:
Hi to all,
after maven-artifact-transfer 0.9.1 is done
I will go forward to make a release of:
maven-dependency-plugin 3.0.1 which contains a Java 8 fix
and afterwards I will go further to release
There are some shared components which shou
Hi to all,
after maven-artifact-transfer 0.9.1 is done
I will go forward to make a release of:
maven-dependency-plugin 3.0.1 which contains a Java 8 fix
and afterwards I will go further to release
maven-deploy-plugin version 3.0.0
this is my plan...
If there are no objections...
Kind regard
I agree with Stephen... we should NOT do binary releases for any other system
than the existing tar.gz and zip to Central/Apache Archive. If users of a
specific ecosystem want to distribute Maven within their system .. fine. But
its up to them to do it. All others like Linux distro packaging
h friendly intent to help your community
> publish their own releases on SDKMAN. I've come back since I was urged to
> do so [1] recently on Twitter by the @ASFMavenProject account.
Twitter is not a good place for discussion.
We currently have 30 steps (some complex) to get a release out the
Hi Maven folks,
I really haven't come here to start a flame war or to give justification
about why/how I built SDKMAN. Even less, justifying why I gave it such a
"silly" name. I have come here with friendly intent to help your community
publish their own releases on SDKMAN. I'
just fyi: github releases has an atom feed.
https://github.com/apache/maven/releases.atom
--
-- Aldrin Leal, / http://about.me/aldrinleal
On Sun, Apr 16, 2017 at 4:49 AM, Marco Vermeulen
wrote:
> Hi Heinz,
>
> On Sun, 16 Apr 2017 at 08:41 Karl Heinz Marbaise
> wrote:
>
> &
Hi Heinz,
On Sun, 16 Apr 2017 at 08:41 Karl Heinz Marbaise wrote:
> Hi,
>
> On 16/04/17 00:56, Marco Vermeulen wrote:
> > Hi Maven folks,
> >
> > Some time ago I asked the Maven dev community whether they would be
> willing
> > to publish their releases on
Ironically, I've ported nvm (for node), but for Maven
<https://github.com/ingenieux/mvm>, but ended up using sdkman later.
I wonder if it would be interesting to have a service to generate webhooks
and rss feeds for new versions/releases on github and apache overall.
--
-- Aldrin Le
Hi,
On 16/04/17 00:56, Marco Vermeulen wrote:
Hi Maven folks,
Some time ago I asked the Maven dev community whether they would be willing
to publish their releases on SDKMAN! [1] using our Vendor API [2].
Unfortunately, my request was met with scepticism and ultimately resulted
in no action
Looks like yet another package manager, and just as most upstream
projects don't provide the packages/build for every linux distro and
package manager system under the sun, this project looks no different.
The sdkman community should help provide the maven releases on it, and
not the
I've started using SDKMAN a couple of months ago and while it's fairly easy
to install maven by downloading the zip/tgz there are still some manual
steps involved. Using sdkman makes it simpler and removes the manual steps.
I don't quite understand the resistance against supporting it. It is a way
Yeah, all I see is a silly name and no compelling reason to look further.
Why should I look at it and how does it make life better? Seen it
mentioned at conferences but just as another way to install something
already super simple to install. So what is compelling about it?
cheers
On Sat, Apr 1
So by sell, I meant an idea too. I'm forever trying to sell things I think
are best, but am not going to make money from.
Can you link to the conversations about the lack of Maven in SDKMAN-land?
Did you understand what I was getting at in my last mail? You didn't
address them, which is your righ
Paul,
I really am not trying to sell anything. I'm trying to help your community.
You will get no *arguments* in favour or against from me.
My users keep asking for Maven on SDKMAN, and I sincerely wish to give them
what they ask for. Whether the community is willing to lend a hand is
entirely up
Marco,
You could sell your idea better, I think. You have "Most of the big
projects want to do this" as one of the stronger arguments in favor, which
isn't enough. For 20 years, Lean/Agilistas have focussed on "what is the
problem you're trying to solve?". And that is the question, I personally*
w
Prior conversation -
https://www.mail-archive.com/search?q=Vermeulen&l=dev%40maven.apache.org
On Sat, Apr 15, 2017 at 6:56 PM, Marco Vermeulen
wrote:
> Hi Maven folks,
>
> Some time ago I asked the Maven dev community whether they would be willing
> to publish their releas
Hi Maven folks,
Some time ago I asked the Maven dev community whether they would be willing
to publish their releases on SDKMAN! [1] using our Vendor API [2].
Unfortunately, my request was met with scepticism and ultimately resulted
in no action taken.
I would like to appeal to the Maven dev
Hi all,
Just a quick heads up that we cut two new releases of the Android-related Maven
plugins.
Android NDK Maven Plugin 1.1.2 - see
http://www.simpligility.com/2016/07/android-ndk-maven-plugin-1-1-2-released/
Android Maven Plugin 4.4.3 - see
http://www.simpligility.com/2016/07/android
pom.xml from original ivy build.xml
attaching test-framework pom.xml for review
(mentioned this to McCandless BTW..but havent heard back)
Merci!
Martin
__
> Date: Sun, 15 Nov 2015 21:10:58 +
> Subject: Re: How the Lucene PMC manages re
ch might get you more testers than you
> > get on the dev@ list.
> >
> >
> > >
> > >
> > > Cheers,
> > > Paul
> > >
> > > On Sun, Nov 15, 2015 at 11:48 AM, Anders Hammar
> > wrote:
> > >
> > >> Tha
missing. When you vote
> an RC, it becomes a formal release, and you can advertise it to the
> user community for testing, which might get you more testers than you
> get on the dev@ list.
>
>
> >
> >
> > Cheers,
> > Paul
> >
> > On Sun, Nov
Paul
>
> On Sun, Nov 15, 2015 at 11:48 AM, Anders Hammar wrote:
>
>> That's how Maven core releases were done in the early v3.0.x days.
>> Personally I think it worked very good.
>>
>> /Anders (mobile)
>> On Nov 15, 2015 15:40, "Benson Margulies
t 11:48 AM, Anders Hammar wrote:
> That's how Maven core releases were done in the early v3.0.x days.
> Personally I think it worked very good.
>
> /Anders (mobile)
> On Nov 15, 2015 15:40, "Benson Margulies" wrote:
>
> > Given the number of 'burned'
That's how Maven core releases were done in the early v3.0.x days.
Personally I think it worked very good.
/Anders (mobile)
On Nov 15, 2015 15:40, "Benson Margulies" wrote:
> Given the number of 'burned' releases recently, I thought people might
> be interested
Given the number of 'burned' releases recently, I thought people might
be interested in hearing about an alternative approach.
When a Lucene dev has a sudden urge to make a release, he or she set
up a release with a version of x.y.z-RC1. This is a real release. It
goes up for a vote.
e made till now and that's positive feeling I guess.
Tibor, my typical dev cycle here is fixes to plugins. I don't claim to
qualified to work on the core. As I wrote, my ability to commit time
to Maven depends on my ability to deliver results in releases. If
someone wants to suggest s
ng
> items are in the JIRA backlog, and make a release, all within a week.
>
> The situation with the hanging 3.0 releases makes this harder. Yea, I
> can make a branch, but it creates complexity and work to have very
> many of these, and I particularly don't want to be creating
backlog, and make a release, all within a week.
The situation with the hanging 3.0 releases makes this harder. Yea, I
can make a branch, but it creates complexity and work to have very
many of these, and I particularly don't want to be creating branches
of the underlying shared components
I keep changing the method signatures from time to time if I discover
there's a better way.
Once released we shouldn't touch method signatures anymore.
It's a matter of rewriting plugins and testing to confirm that all works
as intended.
Robert
Op Sat, 10 Oct 2015 23:58:58 +0200 schreef Tib
What is unstable on it, any non-jira issues?
On Sat, Oct 10, 2015 at 11:31 PM, Robert Scholte
wrote:
> maven-common-artifact-filters shouldn't be a problem.
>
> but the API for maven-artifact-transfer isn't stable enough yet, so please
> don't.
>
> Robert
>
> Op Sat, 10 Oct 2015 21:05:56 +0200 s
maven-common-artifact-filters shouldn't be a problem.
but the API for maven-artifact-transfer isn't stable enough yet, so please
don't.
Robert
Op Sat, 10 Oct 2015 21:05:56 +0200 schreef Benson Margulies
:
maven-common-artifact-filters and maven-artifact-transfer, both 3.0.
Hi Benson,
On 10/10/15 9:05 PM, Benson Margulies wrote:
maven-common-artifact-filters
is depending on maven-shared-utils 0.7..it should be updated to 3.0.0
first...so atm not...
and maven-artifact-transfer, both 3.0.
No other dependencies..so i don't any impediment for this ...
Ki
1 - 100 of 970 matches
Mail list logo
