The sentiment of the community seems to be that the next major release of Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too different from Tapestry 3.0 to be called "Tapestry 3.1". This release will only be largely backwards compatible; applications that sub-class BaseEngine or make use of custom Tapestry engine services will require some amount of re-work. In a small number of cases, component parameters (espcially those using direction "auto" or "custom") will not work exactly as before.
I feel it is completely reasonable to not call this release 3.1, but to continue to bend over backwards for backwards compatibility. A +1 vote signals that you concur, and that the next reelease should be numbered 4.0. This will affect the code in a very limited way: Much code has been added with a @since 3.1 javadoc tag; this will change to @since 4.,0. Likewise, the 3.1 numbering is in documentation, and inside some of the specification DTDs; these will also change. Binding votes: Howard M. Lewis Ship: +1 Geoff Longman: +1 Paul Ferraro: +1 Erik Hatcher: +1 David Solis: +1 Richard Lewis Shell: +1 MindBridge: +0 (no response) Harish Krishnaswamy: +0 (no response) Tsveltin: +0 (no response) Non-binding votes: Jamie Orchard-Hays: +1 Mattew C. Mead: +1 Alex Leong: +1 Brian K. Wallace: +1 Pablo Lalloni: +1 On 4/4/05, Richard Lewis-Shell <[EMAIL PROTECTED]> wrote: > > 3.5 or 4.0 would seem appropriate to me. > > So: +1 > > Howard Lewis Ship wrote: > > The sentiment of the community seems to be that the next major release > of > > Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too > > different from Tapestry 3.0 to be called "Tapestry 3.1". This release > > will only be largely backwards compatible; applications that sub-class > > BaseEngine or make use of custom Tapestry engine services will require > some > > amount of re-work. In a small number of cases, component parameters > > (espcially those using direction "auto" or "custom") will not work > exactly > > as before. > > > > I feel it is completely reasonable to not call this release 3.1, but to > > continue to bend over backwards for backwards compatibility. > > > > A +1 vote signals that you concur, and that the next reelease should be > > numbered 4.0. This will affect the code in a very limited way: Much code > has > > been added with a @since 3.1 javadoc tag; this will change to @since > 4.,0. > > Likewise, the 3.1 numbering is in documentation, and inside some of the > > specification DTDs; these will also change. > > > > Howard M. Lewis Ship: +1 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
