+1 and if you're so concerned about the official beta2/beta3 thing you can just build an official internal release that can be provided on demand to reproduce the problem. I don't see what the problem could be if we explain to the community what we're trying to achieve. It is in their best interest anyway.
S. --- [image: Linkedin] <http://www.linkedin.com/in/snicoll>[image: Twitter]<http://twitter.com/snicoll> On Fri, Aug 6, 2010 at 4:14 PM, John Casey <jdca...@commonjava.org> wrote: > 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 > >
