Planning for next release (1.0.7)

[Jim Pick]

On Thu, 2002-03-21 at 08:44, Mason Loring Bliss wrote:
> 
> On Thu, Mar 21, 2002 at 07:04:32AM -0800, Jim Pick wrote:
> 
> > For future releases, I'd like to propose a version numbering scheme similar
> > to what's used for the Linux kernel.
> 
> Out of curiosity, what is gained by that? It seems somewhat arbitrary, as
> the Linux kernel does it. I'm mostly in favour of the way NetBSD does
> things, FWIW. Release periodically, branching at each release, and simply
> dump new features into the trunk.

I've done some NetBSD stuff too.  It's very CVS-centric though -
personally, I like being able to stick a version number on a
development-only release and make a tarball.  With tarballs, we'll get
more testers if people don't feel like they have to continually check
out HEAD from cvs all the time.

I'm probably just biased because I'm more from a Linux background
(Debian, Kernel.org) than a *BSD background.  :-)

> I'm also in favour of frequent releases, however, so that folks wanting the
> stability of running a release branch never get too horribly far behind.
> This is not an area where NetBSD shines, but there's no reason why Kaffe
> can't do it.
> 
> > When we're in full swing development mode, I'd like to see releases made
> > every few weeks or so.
> 
> Is development active enough to warrant this? Unless there's a crazy amount
> of development going on, I'd think that doing nothing more frequent than
> one release per two months would be a sane minimum span of time. The goal,
> I expect, is to get folks to use Kaffe and start integrating it into their
> work, and having to update more than a few times per year will become per-
> nicious, I expect, when what people most want is a stable platform on which
> to base their Java projects.
> 
> With sufficient change, and with a tradition of quality and stability, of
> course, updates can come more frequently without making the user base too
> nervous. It would of course be cool to see Kaffe rapidly catch up with Java
> 1.4, for instance.

The frequency of the unstable releases would probably depend on whether
there is enough changing to warrant it.  I've got a lot of ideas, and
I'm going to have time to work on it (partly on Transvirtual time), plus
I want to suck in quite a bit more 3rd-party stuff, plus other people
will be contributing, and the project will be more open - so I suspect
that there will be a lot more changes.

The stable releases will probably be a lot less frequent - just a major
new stable release after each development cycle, plus occasional bug
fixes.  Fortunately, we're just reimplementing somebody's else's API
(Sun), so we don't have to worry so much about release-to-release
compatibility of APIs (except for the ones we define).

> Anyway, take all this with a grain of salt. I'm new to Java, and I don't
> have commit access to the repository, so I can be safely ignored. :P

Thanks for the feedback!

Cheers,

 - Jim