I think user issues can be addressed with some naming magic. Instead
of 3.0-beta2 and 3.0-beta3, go with 3.0-beta2, and 3.0-beta2a
It's still "forward", and it implies that they're similar or related
versions, and the notes/announce on it can be clear, but it won't
carry the implication that beta3 is the new hotness and expected bug-
fixes on the road to release, but it's something else. Even if that
just spurs questions, it's the right questions.
Or something else, but not naming them with the same normal sequential
jump is a slightly more meaningful signal.
I'm +1 on the plan of two releases, though, as it does make end-users
who are testing the releases have a lower burden to validate error.
Christian.
On Aug 6, 2010, at 10:44 AM, Arnaud Héritier wrote:
The advantage is to do what I did this morning in few minutes.
I found a OOME on Aether/Guice branch (reported to benjamin but not
in MNG because it's not yet integrated) and then I validated it
wasn't here in current trunk.
The problem is that I had to rebuild both of them hat users won't do.
Without the beta2 release, each time you'll have to check if the
problem reported comes from Guice/Aether or from changes done for
now in beta2.
It is more for you who'll work on it to easily ask a comparison.
As I said we are also not required to do a big announcement for beta
2. We can do it at the same time we do the beta 3 to let users know
it is here in case of issue.
Now it's you're choice. It's you who are doing.
Cheers
Arnaud
On Aug 6, 2010, at 4:31 PM, Jason van Zyl wrote:
Then we wait until we fix it. What difference does a week make at
this point. Honestly?
On Aug 6, 2010, at 10:27 AM, Stephen Connolly wrote:
Given that Arnaud found a bad memory leak in the Aether/Guice
version I
think it would be good to get beta-2 out now without Aether/Guice
Then fix the leak and roll beta-3 as soon as the leak is fixed
-Stephen
On 6 August 2010 15:10, Jason van Zyl <ja...@sonatype.com> 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
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
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
