> Not really. The process Cliff and I outlined is really aimed at getting -a- stable
>release
> available. The process will take at least 2 days to go through but shouldn't take
>more
> than maybe 4 days total. If we use this process AND use your suggestions to not
>commit
> huge chunks of untested code during our 'stabilization period' I am confident we can
>get
> stable releases out on almost every try. We can control the release of tarballs to
>the
> test community.
The only BIG problem I had with Cliff's process of retagging individual
files is that by the time he and OtherBill were finished I had no clue
what was in the actual release version.
How about if we go to the suggestion I posted at the time? Tag what is
believed to be good as APACHE_GOOD, have people check that out as a branch
and bring it up to snuff on platforms as needed, then bump the version and
retag the APACHE_GOOD revisions as APACHE_2_0_XX, and finally merge that
version back into HEAD. That way HEAD can keep going without bounds and
the folks who need a polished release without the latest big fixes can
focus their efforts on the mini-branch.
Personally, as much as I dislike the current lack of a release tarball,
I am more pleased with the rate at which *significant* problems are being
found and fixed in 2.0. In my opinion, the reason 2.0 doesn't have a good
beta release is because it simply has not been ready for beta release -- the
big fixes we have been making lately have vastly improved it over what
it was two months ago.
....Roy
