Although we'll have to discuss that at our meeting next week (reminder:
we have a meeting next week), I'm seriously planning to move on quickly
with check version 0.6.5, by moving the target for the remaining bugs
if necessary. The rationale for that being that the usability
improvements justify the new beta, not to mention obviously that the
actual release is overdue.
It is probably a good time to think of our release cycles (won't
anybody think of the release cycles!), and I think one key to success
in this area will be how and whether we manage to clean up the
HEAD/branch mess.
Don't misunderstand my position though, I still think some branching
was not such a bad idea, but the fact that 0.6 was *not* done after
0.6.1 and that there was very little work on 0.7 for a long time made
the HEAD rot while all work was made in the 0.6branch. Bad luck
happens, but we must do better next time.
My requirements for any solution would be:
- The ability to commit unstable code without fear
- The ability to do some researchy code (modularization)
- The ability for people to download, install, test, have fun with the
Markup validator
- The ability for people to install a stable, working version of the
Markup validator
- The ability to do a very quick fix to the :80 (e.g broken links)
without it being too big a burden
Thinking ahead, I don't think we'll have resource swarming toward us in
the near future. IOW, developing a new modular codebase and fixing all
the bugs in the monolithic one does not seem too reasonable. Thus we
may have to decide between ditching all hopes of a new, clean
generation in order to fix all the bugs in our current service, OR
leave the service as is (reasonably - ahem - stable and bug-free) and
develop a new generation.
Depending on which path we choose, I can see a few possibilities for
our management of CVS:
1 - stay as things currently are
2 - invert... HEAD would be the current work (synced with 0.6branch -
can we do that, technically? - or removing the 0.6 branch) and advanced
development would be done in a specific branch
3 - no more branches.
4 - two branches, stable and unstable
My opinion is still fluctuating, and I'd like to discuss this seriously
with all of you. So far I think we have reached the limits of our
monolithic+openSP design, and tweaking it to death to fix XML related
bugs may just take more effort than re-starting with a multi-parser
design. I would then favour option 2, or option 1 (2 being more
friendly to semi-clueless people wanting to get something slightly more
*cutting edge* than the tarball).
[YOUR THOUGHTS HERE]
--
olivier