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