Dom,
Thanks. I'd been assuming we should be able to easily converge on a release
we could all be proud of. You've really reassured me.
Unless I'm missing something, we're in agreement on all of the following
points, in no particular order:
- 0.7.12 is really stale, and needs to be replaced pronto
- bugs should be fixed as they're found, not saved for later
- features should be finished so they Just Work now, not later
- more QA help of any kind would be *invaluable* for this
- 1.0 is the beginning, not the end
- the 1.0 roadmap is even more fictional than it always was
- 0.9 should have a strong resemblance to 1.0
- large projects often get stuck too long in "pre hell"
- there will be post-0.9 sneakins
I also agree very very very strongly with the following statement:
At 02:32 PM 2/16/01 -0500, Dom Lachowicz wrote:
>But I'd argue that these were pre-releases before a
>*major milestone* release, which I'm arguing that our 0.9.0 definitely
>represents. 0.9.0 is a huge step for our team, and we're definitely close.
>We deserve as much.
Absolutely. I agree wholeheartedly that 0.9.0 is a major milestone whose
importance can't be overstated. This project took **huge** leaps in
visibility at each of the following milestones:
0.1.0 -- first source release
0.3.0 -- first GPL release
0.5.0 -- first tradeshow ("Show me the Source!"
0.7.0 -- first binary release
There are a lot of people who've been waiting to experience all the whizbang
features and stability promised by calling something our 0.9.0 release.
Things we should expect on that day include:
- a top-level story on Slashdot, etc.
- probably a few mentions in the tech press
- enough download traffic to make SourceForge sit up & notice
- lots of ensuing complaints and flamage
That's a pretty big splash. A lot of my reluctance to use the 0.9.0-pre
label now is because we're not (quite) ready for that kind of attention.
Yet.
Still, those are 0.9.0 issues, and none of them come into play if we go
ahead and label the next release as 0.7.13, publically stating that we
expect this to be the *last* 0.7 release.
bottom line
-----------
I think the one remaining obstacle for me on today's proposed release is a
nagging sense that we haven't quite closed the loop on our usual
"pre-release stabilization" activities. I loved your email earlier this
week, but I think we fell a bit short on the follow-through.
A bunch of new features have landed in the tree recently -- especially
editable headers and the reworked lists dialog -- and frankly, I doubt that
most of us have even rebuilt and tried them out yet.
This is something that we each have to do for ourselves -- see if the latest
stuff Just Works -- if we want to feel confident that we're releasing
binaries that we can be proud of. (I'm quite frustrated that it took me so
long to get to that point myself, and I still haven't posted the
Win32-specific dogfood issues. TODO.)
It's quite clear that the key GNOME and GTK folks are ready to release, but
it makes me nervous that we haven't heard anything either way from the
maintainers of the other platforms -- QNX (Thomas), BeOS (Christopher), or
Win32 (Tom and/or Mike). We haven't even had the quick poll to hear:
"Sure. I like what I've got."
"Please wait for (n<5) days so I can fix (a,b,c)."
"Sigh. Go ahead without me. I'm just too short on time."
If you've already heard that privately from one or two of those folks, then
we're not jumping the gun. I just haven't seen it here.
>If this is the case, I'd like a relatively quick cycle from 0.7.13 -> 0.9.0
>if there are no major objections. Our release cycles are too long as it is
>now...
Yes, our release cycles are definitely too long. Perhaps a useful precedent
would be if people could pick up on Jesper's example of posting a dwindling
TODO list of tasks, broken down into milestones.
Then, at release time, it should be pretty easy for people to post release
proposals in the form of checklists, by feature, to summarize what's done
and especially what's still left.
By shining a spotlight in this way, we can all tell how rapidly the next
release is coming, and how much work we'll each need to do to get our work
ready, too. As soon as the prerelease checklist is done, we ship.
Paul
