Being one of the voters for the cache management issue, :-) I agree that flexibility is your best approach right now to achieve an early beta. Make it possible for users to plug-in their own cache implementations, like they can do for resolvers and so on. Later you can take in the best implementations and make them part of the official distribution if you so choose.
For example, right now in my company we are having issues with concurrent updates to the cache, and we are trying to solve it by using the available hooks. But it would be better to be able to replace the entire cache engine with an implementation that manages critical sessions internally. /Nascif -----Original Message----- From: Xavier Hanin [mailto:[EMAIL PROTECTED] Sent: Friday, August 24, 2007 10:16 AM To: [email protected] Subject: Re: 2.0 beta 1 On 8/24/07, Gilles Scokart <[EMAIL PROTECTED]> wrote: > > 2007/8/16, Xavier Hanin <[EMAIL PROTECTED]>: > > Hi, > > > > last june I think we agreed on something like that: > > 2.0-beta-1: (bug fix + code cleaning + tutorial) late august > > > > I fear that we are late Agreed :-) > We are now at the middle of august, can we try to see if we still plan > to > > release beta 1 before the end of the month, and see which issues we > would > > like to address in this version. > > > > On my site, what I have pending is the end refactoring to isolate the > settings per engine. I would also fix the bugs conerning the relative > path handling. > > > IMO, to make it a beta version, we need to work on the tutorials to > > make sure all of them are up to date and in sync with 2.0 changes. > > Fixing > some > > more bugs would be nice too. We have already made pretty good > > progress > on > > code cleaning, a little more wouldn't hurt though. Nothing > > unfeasible in > a > > couple of weeks, especially if we agree to split the (not funny) > > work required on the tutorials. > > > > Yes, I think that's required. My problem is that I have little view > on what is required in the tutorials. > > My first guess would be that, the current one must work, and the doc > must be updated. Exactly, that's what I was thinking about. But I don't think that's not funny. I have an idea that are I think > could be interresting to do: > 1. Write an ant script that run every tutorial example and check its > result. > 2. Put that script into gump > 3. Update this script (and the possible the doc)so that the output of > each tutorial execution is saved and can be integrated in the doc > (maybe with iframe?) For the third item, it would be very nice, but I fear it will be quite difficult to achieve. Each tutorial runs several steps, and do not display each the full output of each step. So we'd need some kind of metadata to describe what we really want to capture. If you have ideas, that's nice! But IMHO I'd stick with a human effort to follow the tutorials and check if they are still working and accurate. If you think having the captures separated from the rest I can add a file inclusion feature in xooki, this is simple to achieve, and will be more flexible than an iframe (we could generate an iframe, or include the content, or whatever). It could be something like {{ ouput-step1.txt}}. Is there anyone who want to contribute? > > > The date planned for the first 2.0 RC is approaching too (late > september), > > so maybe it's time to agree on what to include in 2.0. I think we > > should first focus on bug fixes and documentation update, then on > > maven 2 compatibility. The flexible cache management has raised some > > interesting discussions and is still by far the most voted issue (12 > > votes). Should > we > > try to address it at least partially in 2.0, which could imply > postponing > > the RC cycle? > > > > I think we are late. We don't have anything to release for the > moment, but we should not neither wait too long. What do you think > about. > - Making the tutorial enhancements, then make a new release of the > site Sounds like a good idea - Working on some fix, then make a 2.0-alpha-3 as soon as we have a > minimum to release I'd call it beta 1 as soon as we don't plan to change major things after this release. A beta will attract more users, and I think our current code base is already stable enough to start adoption. - Make the 2.0-beta1 when we have the major issues fixed (including > the maven compatibility). If we have all major issues fixed maybe we can call it a release candidate? Or if we still plan to make changes we can go on with other betas, but I'd like to make a release candidate cycle before the final release. - Then, rather quicly go to beta-2 and 2.0. > > And concerning the cache managment issue, I have a problem : I don't > know what is asked. I have the impression that 12 persons voted for > it, but everyone has a different demand. So, before saying that we > can put it in 2.0 or not, someone has to sumarize what is asked to see > what is the concensus on that. You're probably right... The problem is that it will be difficult to introduce a whole new cache management in a 2.x version once 2.0 will be out. So maybe starting to improve our cache management and making it more flexible in 2.0 would be better. On the other hand I think releasing 2.0final before the end of the year is very important, and I don't want to try to implement a feature if it forces us to postpone the release. But I can work on this issue and try to make our cache management at least a little bit more flexible, it could be a good start to help users discuss about what they really need, and to reach a consensus about it. WDYT? Xavier -- > Gilles SCOKART > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/
