<ignoreVersions>
<ignoreVersion>20090607.12544900</ignoreVersion>
<ignoreVersion type="regex">\d{8}\.\d{6}-\d+</ignoreVersion>
</ignoreVersions>
Is what I would suggest. Ie the type attribute defaults to "exact"
On Tuesday, 13 November 2012, Dennis Lundberg wrote:
> Sure, I'll do some more testing and then commit it. Do you have an
> opinion regarding naming for this new feature?
>
> See my last comment on the issue:
>
> http://jira.codehaus.org/browse/MVERSIONS-144?focusedCommentId=313386&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-313386
>
> On 2012-11-13 17:32, Stephen Connolly wrote:
> > OK, good to know.
> >
> > If you are happy to update jira to target MVERSIONS-144 for 2.0 and
> > commit it to trunk that would be a help.
> >
> > I just want to get off the 2.2.x compat sauce and get over to 3.0 as a
> > minimum as there are a lot of bugs that are near impossible to fix
> > without being on a consistent dependency resolution API... though
> > Hervé's dependency tree component might be able to solve some of those
> > issues... I have not checked.
> >
> >
> > On 12 November 2012 19:43, Dennis Lundberg <denn...@apache.org<javascript:;>
> > <mailto:denn...@apache.org <javascript:;>>> wrote:
> >
> > On 2012-11-12 13:04, Stephen Connolly wrote:
> > > Dennis,
> > >
> > > The roadmap that I set out for v-m-p only has one issue tagged
> against
> > > the next release (2.0). That release is to be the last release
> > > supporting Maven 2.2.x. After that the next release is 3.0 which
> will
> > > require Maven 3.x.
> > >
> > > My intention had been to roll 2.0 and 3.0 fairly quickly after each
> > > other and the previous v-m-p release (1.3 allowing for the JDK 1.4
> > > compat bugfix that was 1.3.1) However, things got in the way and I
> > > didn't get to roll 2.0 in March and 3.0 in April.
> > >
> > > I think 2.0 is good to go... though I should probably cut that
> > > from r15892. If you want to review what has changes since then and
> see
> > > what is worth pulling into 2.0 perhaps we should stash the current
> > trunk
> > > in a branch and get the 2.0 out the door.
> > >
> > > I will give a week or so before I start preparing to cut 2.0. I
> > can see
> > > value in maintaining a 2.0 branch if somebody else wants to take
> > up the
> > > role of maintainer for that branch after I push it out... just as
> > there
> > > is the option there for anyone who needs Maven 2.0.x compatibility
> to
> > > maintain the 1.x branch of v-m-p... most likely not seen as an
> issue
> > > until 2.0 is released.
> > >
> > > -Stephen
> >
> > Hi Stephen
> >
> > My main goal it to get MVERSION-144 into a Maven 2.2 compatible
> version
> > of the Versions Plugin. I only started looking at other issues
> because
> > the ITs were failing for me using Maven 2.2.1. I don't see any
> problems
> > with MVERSION-144 for Maven 2.2.x, do you?
> >
> > I've taken a look at the changes after r15892, and AFAICT there is
> only
> > a single commit, made by myself, that fixes a typo in Javadoc. So
> it's
> > safe to say that that change is backwards compatible :) A release of
> 2.0
> > could be made from trunk as I see it.
> >
> > --
> > Dennis Lundberg
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
