Alpha, beta, gamma, .. [Was: Re: [jdom-interest] detach() [eg]]
elephantwalker at home.com
Fri Apr 27 10:49:25 PDT 2001
I agree on this one.
Pick a day. Freeze the product, start the beta-program, only fix
Move everything on the dev tree after the freeze to 1.1.
As a very famous manager once said "It's time to shoot the engineers, we
have to release the product!"
From: jdom-interest-admin at jdom.org
[mailto:jdom-interest-admin at jdom.org]On Behalf Of Thomas Koch
Sent: Friday, April 27, 2001 12:51 AM
To: jdom-interest at jdom.org
Cc: jdom-interest at jdom.org
Subject: Alpha, beta, gamma, .. [Was: Re: [jdom-interest] detach() [eg]]
To avoid any misunderstanding, I think JDOM is a great API which
has provided a slim solution to many problems we've had with DOM based
XML processing. We have been able to achieve 2 to 3-fold improvement in
processing speed on reading and digesting XML while the memory footprint
was reduced by 80%. Thanks for starting this at the right time!
However, I can't resist to support Dennis' definition of a beta-version.
(My definition of alpha would be even stricter than his which in
my opinion is a 'prototype'.)
According to those definitions, JDOM is currently somewhere between
alpha and beta. Some parts of the API are very stable. It is obvious
that the JSR could effectively change a lot of things.
But, having worked with everything between b4 and b6
the advantages have by far outweighted the problems of upgrading
and API changes have been quite manageable during this period.
Also, due to a alpha/beta stage, it requires some own testing and QA
(which has shown very few problems) before making it part of your product.
If the API is undergoing drastic changes (not additions!), it will,
no doubt, create work for current users operating near production stage.
Perhaps a real freeze (like JDOM 1.0) could be considered before
such major API changes happen. What is the problem of starting
JDOM 1.1 or 2 which will be compliant with the JSR?
This is mostly a psychological issue, but would be perceived as a
more stable anchor point in the stream of development iterations than,
lets say, 1.0b6. This is just a suggestion, not a "requirement".
On Thursday 26 April 2001 21:44, Dennis Sosnoski wrote:
> In projects I've worked on "beta" generally means that something is near
> production release and fairly stable. This as opposed to "alpha", which
> generally means nothing is fixed and it's just for demonstration purposes.
> Not to beat this issue any further, but the text on the download page
> the betas under Milestone Builds, with the text:
> "Milestone builds indicate large additions in functionality, or
> pre-release, feature-frozen builds that may soon become release builds.
> Although generally stable, they often contain new features that are still
> being tested for their value and usability. These are great for developers
> and users trying to see what is coming in the next versions of JDOM."
> This is accurate in and of itself, but the "or" in the first sentence is
> certainly misleading - none of the Milestone Builds to date could be
> considered "pre-release, feature-frozen builds that may soon become
> builds." I think it'd be more accurate if this part were eliminated for
> now, and if a specific warning were given that "the APIs are subject to
> change without backward compatibility and any code written to the current
> APIs will likely need to be changed for future releases."
> - Dennis
> philip.nelson at omniresources.com wrote:
> > > I'd suggest that if this is the case there should be a
> > > warning to developers on the
> > > download page that all "beta" builds should be considered
> > > trial only and are not
> > > intended for production work.
> > What does beta mean then?
To control your jdom-interest membership:
More information about the jdom-interest