There is one huge advantage to two releases, however:
You know that if the bug exists in both places, you don't have to dig
through this huge pile of code that is the new container. That's a large
set of assumptions you don't have to check.
On 8/6/10 10:10 AM, Jason van Zyl wrote:
On Aug 6, 2010, at 10:01 AM, Brian Fox wrote:
2010/8/5 Arnaud Héritier<aherit...@gmail.com>:
Ok,
Thus talking is good but doing is better ( I know I'm talking more than I'm
doing :-) )
Could we have a consensus if we :
- release now the trunk as a beta 2 without Guice and Aether. With that we'll
have a solid base to compare future changes with. We know it is stable and it
is better than beta 1 (it solves some issues like for the site plugin and also
in // builds). If the vote is called now we can deliver it to users for Monday.
- just after the beta2 release we merge changes required for Aether and Guice
and we start the release process for a beta 3 we'll deliver at the end of next
week.
mvn:release prepare release:perform takes at most 30 minutes so I
don't see any harm in firing them both out there.
Other then it being highly confusing to the general user base. We have beta-2
and then three days later trying to message making two drastic changes and
releasing it again. Also what this entails is that if someone does report a
problem with the container or artifact resolution it will have to be addressed
in beta-3 anyway. If we're going to release a beta-2 that is effectively not
going to be support I don't see much value in that. Also between Stuart,
Benjamin, Igor, and myself anything in the container and resolution level will
get fixed quickly.
Why don't you just try the site plugin with the branch with Aether and Guice
and make sure it works? I think taking the time to make sure those changes work
is better then dealing with the WTF responses from users when we drop two betas
out in the course of three days. The vast majority of users are not using
3.0-beta-1 and so I don't think the average user cares that a the site plugin
doesn't work. I would prefer we delay a single decent beta of what we are
ultimately going to ship.
It's not hard to spin out two releases, but it's just harder to manage because
when issues come flying in we're dealing with two completely different animals.
People are unlikely to specify the right version and we're just going to have a
lot more busy work then necessary.
Let's make one good release wait a week and push out what we actually plan to
support.
I personally think dropping out two betas that are completely different in the
span of 3 days is just totally confusing for users and not the tone we want to
set building up to the release of 3.0.
With that we'll try to receive feedback from users and we'll easily validate
if problems are related to Guice or Aether by comparing results with both
versions.
At the end of the month we can push out a new beta with all fixes we'll have.
It will be always possible to decide to remove Aether if some of you have a
better solution or aren't satisfied by the change (I would prefer to have done
that in an alpha releases cycle but now we are in beta we cannot come back in
rear).
WDYT ? I think it is important to push out new releases to show to our
community that we are always active and we are going in the good direction.
Arnaud
On Aug 5, 2010, at 11:06 PM, Dennis Lundberg wrote:
Hi all
Some very important questions have been asked regarding Jason's
proposal. I usually let my first impressions sink in a bit before I
reply. That often help to make my comments more about the facts and less
about the feelings, and we've seen a lot of feelings in this thread.
The first thing I would like to happen is that we release 3.0-beta-2
*without* merging the proposed code. There are two reasons for this.
1. The Site Plugin, which most of you know is something that I've worked
quite a lot on, is currently in limbo. On one hand we have the stable
2.x trunk of the plugin which works with Maven 2, but not with Maven 3.
We also have a 3.0-SNAPSHOT branch of the plugin, thanks to Olivier and
Hervé. But that currently don't work with any released version of Maven
because of a bug in Maven 3.0-beta-1. In order to gain momentum and
field testing for Maven Site Plugin 3.0 it needs a stable version of
Maven to work with. There are too few people working on the Site Plugin,
and if it needs to be rewritten yet again there is a risk that it will
never be ready.
2. Release early, release often. Give the users a choice here. They can
choose to use Maven 3.0-beta-2 which will work much like beta-1 did, but
with lots of bugs fixed. Or a few weeks later they can use 3.0-beta-3
the proposed code changes merged in. If the new stuff doesn't work, for
whatever reason, they can switch back to beta-2 while they wait for a
bug fixed beta-4.
As for they proposed code bases I am not qualified to make detailed
comments, so my comments will be very high level.
Guice
IIUC this means that we would replace one (external) IOC container with
another (external) IOC container. If the bar for being allowed to
participate in the development of Guice is at the same level as it has
been for Plexus, then I have no problem with this switch.
I am +1 on integrating the Guice code after beta-2 has been released.
Aether
One thing that I really think has been successful here at Maven has been
when we have set up proper APIs that abstracts the implementation and
let the users pick a suitable implementation for their needs. Two
subprojects come to mind: SCM and Wagon.
If the API part of Aether is anything like that, then that's a good
thing in my book. I haven't looked at the code, only the high level
presentation, but I have high confidence in those who have worked on it.
Having the API hosted outside of Apache is fine by me if it means that
more projects will use it. The more the merrier.
When it comes to the implementation I'm undecided. It does mean that we
will make an integral part of Maven external, which can lead to problems
with issue tracking etc, as pointed out by others. On the other hand it
makes sense to use the collective knowledge of the people who is
responsible for the API, to also work together on implementations.
Perhaps the Maven repository implementation can be moved back to the
Maven project, when things have settled down.
I am +0 on integrating Aether after beta-2 has been released. I'll let
others with more insights decide.
On 2010-08-03 20:21, Jason van Zyl wrote:
Hi,
We have two major pieces that we, Sonatype, would like to merge into Maven 3.x
trunk.
The first are the Guice changes that we've been talking about for a while, and
the second is the introduction of Aether which is our second attempt at a
stand-alone repository API. The PMC is aware of Aether as Brian reported it in
our quarterly report to the Apache Board, but other developers who are not on
the PMC and the community in general might not know much about it.
I just posted an entry giving a very high level description:
http://www.sonatype.com/people/2010/08/introducing-aether/
There is a resources section at the bottom of the post for those interested in
the sources, issue tracking, wiki and mailing lists. As part of some of the
research we are about to embark on with Daniel Le Berre, Aether will likely
look more like p2 as time passes and as a final resting place the Eclipse
Foundation is more likely then Apache. I know people will ask so I'm answering
that now. Sonatype is just about to fully move Tycho over the Eclipse
Foundation and we want to see how that goes. If that works, then M2Eclipse is
next, and then Aether will follow.
At any rate we would like to merge these changes in and make plans to release
3.0-beta-2.
So please let us know if you have any objections.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
--
Dennis Lundberg
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
