5:30 PM
To: Maven Developers List
Subject: Re: MNG-624 automatic parent versioning
On 13/06/2008, at 2:05 AM, Brian E. Fox wrote:
> Perhaps, but 10 releases into a branch isn't a great place for
> innovation
> either.
I agree, but with that being the case we need a featu
On 13/06/2008, at 2:05 AM, Brian E. Fox wrote:
Perhaps, but 10 releases into a branch isn't a great place for
innovation
either.
I agree, but with that being the case we need a feature development
location that we are confident enough to release.
Given that, I think we need to move imme
Perhaps, but 10 releases into a branch isn't a great place for innovation
either.
On 6/12/08 10:40 AM, "Ralph Goers" <[EMAIL PROTECTED]> wrote:
> I wouldn't be quiet so harsh. Of course stability is great and should
> always be strived for. But so is innovation.
>
> For me the key is all about
I wouldn't be quiet so harsh. Of course stability is great and should
always be strived for. But so is innovation.
For me the key is all about compatibility. If a feature can be added in
such a way that by default nothing changes, then we should lean towards
putting it in. If it cannot be done
This is something that I think we don't want to put into 2.0.x at this
point. We need to be focusing on stabilizing the issues and knocking out
regressions, not introducing new places to hose people.
-Original Message-
From: Dan Fabulich [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11,
would it be possible to remove the default relative path... if people want it
they can add it... ../pom.xml just seems very arbitrary
maybe if you want group based parents it makes sense , i have found real power
in using functional parents that define all the plugins for a particular type
of
On 11-Jun-08, at 6:47 PM, Dan Fabulich wrote:
MNG-624 (automatic parent versioning) is far and away the most
popular MNG issue with 85 votes (the next highest has 57).
In June of last year, Jason evaluated the attached patch and found
problems with it, but the problems weren't specified
On 12/06/2008, at 12:45 PM, Dan Fabulich wrote:
Brett Porter wrote:
I haven't reviewed the patch, but the comments by Eric about what
he did sound quite reasonable to me.
Me, too.
- ensure that when deployed to the repository, it is *always* set.
A POM in the repository with a versionle
Brett Porter wrote:
I haven't reviewed the patch, but the comments by Eric about what he did
sound quite reasonable to me.
Me, too.
- ensure that when deployed to the repository, it is *always* set. A POM in
the repository with a versionless-parent would be considered invalid (this is
the m
I haven't reviewed the patch, but the comments by Eric about what he
did sound quite reasonable to me.
Off the top of my head, the rules for this behaviour would be:
- use the POM found in relativePath (default, ../pom.xml) first
- if checked out independantly, use RELEASE
- ensure that when de
10 matches
Mail list logo
