There you go, we agree. Grid away!
On 2009-11-02, at 8:28 AM, Stephen Connolly wrote:
2009/11/2 Jason van Zyl <ja...@sonatype.com>
On 2009-11-01, at 11:49 PM, Stephen Connolly wrote:
2009/11/1 Jason van Zyl <ja...@sonatype.com>:
I think it's akin to the surefire plugin. Where it's been so long
that if
we
release this and people get the automatic updates and something
is wrong
it's not so fun.
Well how about we release a 2.1-alpha-1 and up its minimum maven
version to 2.0.9
That way anyone with earlier than 2.0.9 will not be able to use the
alpha and anyone with 2.0.9+ will have a lock-down in place.
Another way would be to release 2.1-alpha-1 as 2.0.3-alpha-1-for-2.1
and re-release 2.0.2 as 2.0.4.
If we stage them in one repository and then promote that
repository in
one go then anyone using 2.0.8- will just use m-c-p 2.0.4 which
would
be identical to 2.0.2, and we can get people with lock-downs to try
the newer version.
You also just simply have to worry that it works. For people who do
actually upgrade. It needs to be tested thoroughly before it's
released,
this just needs to become a priority for core plugins. Just get
something
working on the grid and think we will have done the best we can do.
Which was what I said below!!!
Maybe you and Benjamin can sort out a way to stage the plugin and
run all
the projects on the grid to see if it's all good. A similar
strategy
could
be employed for the surefire plugin. The best we can do is run as
many
projects as we can with these new plugins to make sure they work
in the
wild
as we've seen in the past that sometimes the releases are not so
stellar.
Yes I agree that this could be a first step. Then we could try as
step 2 a 2.1-alpha-1 with the minimum maven version upped to 2.0.9
and
finally we can roll the 2.1 release with maven 2.0.6 restored as the
minimum version.
Thoughts?
Also, we will need to get surefire out the door. There are some
good
fixes in that, but let's get compiler out the door first and
establish
a process for that.
^^^ See above!!!
;-)
Stephen
I'm sure we could find a clean place to inject an override for the
default
version of the compiler plugin in 3.x and then use that version
of Maven
to
build as many on the grid as we can. Can't think of a better way
to test
a
core plugin to make sure we don't hose anyone.
On 2009-11-01, at 12:59 PM, Stephen Connolly wrote:
Now that we have maven-toolchains-plugin released, what is blocking
rolling a release of maven-compiler-plugin?
Toolchains support has been integrated since r649442. All the
integration tests (3 of them) are passing. I am not seeing any
issues
in JIRA which are regressions (i.e. releasing now would probably
not
make things worse)
There are currently 3 critical issues in JIRA:
MCOMPILER-98 is an issue for plexus-compiler
MCOMPILER-64 is just a higher memory requirement for large
compiles with
jdk6u4+
MCOMPILER-43 looks to be a plexus-compiler-eclipse issue
If all that is somebody to play release manager I'll go running
again.
If getting a release requires applying patches or fixing issues
I do
not have the cycles at the moment
-Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
