[kaffe] Planning for 1.1.3 release

[Jim Pick]

On Fri, 21 Nov 2003 19:50:19 +0100
Dalibor Topic <robilad@kaffe.org> wrote:

> Hi Jim,
> 
> Jim Pick wrote:
> > Hi,
> > 
> > It's getting to close to that time again.  Isn't having a regular
> > release schedule fun?
> 
> Yep. I'd actually propose a faster release schedule: once a month after 
> 1.1.3. There is so much changing every two months, that the steps 
> between releases are quite huge, so that people following developer 
> releases instead of CVS may have a harder time reporting bugs based on 
> releases only.

I originally hoped to do the developer releases monthly, but I find that
it usually takes an entire weekend to get it out, so I'm happier with
the two month schedule, just from a personal time commitment
perspective.  I imagine that when the big merging settles down, it
should be less of an issue.

> > This should be the last development release before we get serious about
> > putting together a real production release.  Here's the dates I have
> > penciled in for that:
> > 
> > 
> >>Sunday, January 18, 2004 - Feature Freeze for 1.2.0
> >>Sunday, January 23, 2004 - Release Candidate - 1.2.0-rc1
> >>Sunday, February 1, 2004 - Release Candidate - 1.2.0-rc2
> >>Sunday, February 8, 2004 - Release 1.2.0 (Production Release)
> 
> I'm not so optimistic about a stable release that soon, as I don;t think 
> we should really cut that one based on time passed alone, but also 
> define a list of features we want to see in, as well as platforms we 
> want to see run, applications we want to offically list as supported in 
> 1.2 etc. For example, I think we shouldn't release 1.2 before the switch 
> to GNU Classpath is completed.

Okay, I think some release goals would be a great thing to have.  On the
other hand, I don't want to have 1.0.7 on the website as our "production
release" for too much longer, so I think we should still pick a date.
Eighteen months between production releases is already a long time.

If we slip on the goals, then we can postpone the release.  Since we
don't have dedicated developer resources, we've got to be careful that
the slippage doesn't get out of hand, or the release will never happen.
So we should keep the goals pretty minimal.

I believe that a real solid, "supported" production release would really
encourage a lot more people to give Kaffe a try, and to get more
involved.  A perpetual stream of unsupported "developer" releases won't
do that.

Let's postpone setting a date for the production release until after
1.1.3 is out.  Maybe we'll do a 1.1.4 development release.

We need to have a discussion about what should constitute the release
goals for the production release.  I think that will be easier once we
have some decent documentation that shows where we are.

Given the "moving target" nature of what we are doing, we might want to
identify a core set of APIs, ports and features that we "support", and
mark the rest of the stuff as "experimental/unsupported".  It would be
nice to identify certain applications and certify that certain versions
of them work on the Kaffe production release.

> I'm glad to hear it's actually working for something, browsing the list 
> traffic I sometimes catch myself thinking: how are we ever going to fix 
> all these bugs ... ;) But I guess that's just the effect of kaffe 
> getting better, and more people trying it out where it hasn't been tried 
> out before (or for a long time ;)

That's so true... :-)

Cheers,

 - Jim