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/
