On 1/31/06, Bernhard Slominski <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I am a bit confused about the versioning and the API stability.
> So the current Version of Shale is 1.0.1 (according to the API
> documentation), so a 1.0 version.


Shale follows the same version branding policy that the rest of Struts does
(along with Tomcat and some other projects).  An "x.y.z" release is first
issued with no "quality" metric, and is then voted on as being of alpha,
beta, or general availability quality.  The 1.0.0 release was voted to be
alpha quality (in spite of the fact that many portions are more stable than
that would imply) as a whole.

However the API stability
> (http://struts.apache.org/struts-shale/api-stability.html) tell a
> different
> story, from the 32 packages only 7 packages are "evolving" that means
> backwards compatibility is maintained.
> So from the API stability it looks more like a < 0.5 release status.
>
> So my question: In which version can the status "evolving" for all
> packages
> be expected? Or will there be always some packages in the "developing"
> status?
>
> I understand that according to the Struts FAQ there will be no release
> schedules (http://struts.apache.org/helping.html#release), I read it,
> understood it and accepted it, however if someone's got a rough estimate
> I'd
> be happy to hear about it.


I would expect that there will always be *some* amount of new functionality
that is not as API stable as the older portions of the framework.  But, I
would also expect that the majoirty of the existing packages would get
flipped to "Evolving" before a General Availability release was proposed.
On the other hand, don't be surprised at additional intermediate 1.0.x alpha
or beta quality releases that both improve on the existing APIs and flesh
out the functionality of the framework as a whole..

So why not just do that?  It's really simple ... not enough feedback yet
that we have the APIs right.  That means people need to be willing to try
the evolving APIs and tell us where we've got them wrong, so that they can
be fixed *before* committing to backwards compatibility.  For that reason, I
would not necessarily be personally afraid of using APIs in the "Developing"
category -- that's the only way you'll be able to take advantage of recent
trends and featgures, as well as to actually move those APIs forward in
their stability.

Thanks
>
> Bernhard


Craig

Reply via email to