On Jan 5, 2014, at 2:53 PM, Kristian Rosenvold
wrote:
> I just see little point in pissing off users with extensive breakage if we
> have simple means of assessing the consequences before we do it.
I'm not disagreeing with you about running what we have and knowing what
breaks. It's easy eno
I just see little point in pissing off users with extensive breakage if we
have simple means of assessing the consequences before we do it.
Deprecations come in all sorts, some turn out to be like the "new" style
configuration for the site plugin; where exposure to the wild revealed that
the old so
In general for deprecated code that's in the year or so old range I think that
strategy is fine. We just haven't been very good removing stuff.
In the case of this code it's had the deprecated warning for a long time and if
it's removed and it breaks code then that code needs to change IMO. If t
On Jan 5, 2014, at 6:27 AM, Stephen Connolly
wrote:
> I guess my question is, why have we still not cut 3.2... If the answer is
> just nobody has bothered, then I'd be happy to give a spin through it...
Release it why? Simply because of 1.6? I don't think that's a particularly good
reason. We
I think we should remove any deprecations that do not break trunk of
maven-plugins and mojo-trunk, and call it 3.2; at least do this as an
initial move. Then we can determine the scope of /use/ of deprecations.
I am very skeptical to removing stuff wholesale "just because" we
deprecated it 4 years
I guess my question is, why have we still not cut 3.2... If the answer is
just nobody has bothered, then I'd be happy to give a spin through it... If
the answer is bugs needing a fixing then let's get those out of the way and
spin that release already... Then we can have a clear run at 4.0 with
dep
My PoV is that once Java 8 is released we drop support for running on Java
6 (keep support for compiling with a Java 6 JDK via toolchains)
We should be one and one back with regards to the runtime JVM maven
requires.
But to get there I'd like to see a JDK 6 min release first, gauge how the
commun
I missed jvz's question: yes for removal of deprecations eagerly. If
anything, we should start doing that eagerly (4 years?), and declare this
step as transitioning one toward 4.0?
thanks,
~t~ (mobile)
On Jan 5, 2014 11:29 AM, "Tamás Cservenák" wrote:
> As i mentioned in referenced thread, i wou
As i mentioned in referenced thread, i would really like to see maven at
java7.
We talk about release to happen in near future, that would be used in a bit
further future by users, but even _today_ there is no other java than 7
that is not eol-d. For those locked in, there are still 3.0, 3.1 relea
On Saturday, 4 January 2014, Jason van Zyl wrote:
>
> On Jan 4, 2014, at 4:56 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com > wrote:
>
> > Doing so would make the next version 4.0 and not 3.2
> >
> > I don't mind if we want to do that, but we were supposed to be pushing a
> > 3.2 out at
On Jan 4, 2014, at 4:56 PM, Stephen Connolly
wrote:
> Doing so would make the next version 4.0 and not 3.2
>
> I don't mind if we want to do that, but we were supposed to be pushing a
> 3.2 out at the start of Oct and I do wonder what the status is there
>
3.1.1 was released on September 17t
Doing so would make the next version 4.0 and not 3.2
I don't mind if we want to do that, but we were supposed to be pushing a
3.2 out at the start of Oct and I do wonder what the status is there
On Saturday, 4 January 2014, Jason van Zyl wrote:
> I'm doing some cleanup in the core in preparatio
I'm doing some cleanup in the core in preparation for some refactoring I'd like
to propose in the coming months and the deprecated methods in MavenSession
have been there for over 4 years. I'd like to, at some point soon, be able to
move the core and plugins to toward being fully JSR330 so I'd
13 matches
Mail list logo
