This looks like a great plan.  I'm excited to see 1.5 out the door.

On the planning note, i hope to get VelocityTools 1.2 out before
Christmas (i really want it to beat 1.5 out of the gate, if only by a
little bit).  the only real holdup there is the Tomcat 5.5 issue and
giving some attention to velstruts.  That may be the last in the 1.x
series for veltools, unless someone really steps up to carry on with
it.  i'm ready/needing some big changes to the organization and
structure of veltools.  i'd like to move on those this spring and be
able to add dependency on Velocity 1.5.

On 9/30/05, Will Glass-Husain <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I wanted to start some discussion on a release plan.  Here's my ideas - any 
> comments?
>
> Summary
>
>  1.5-beta  (late October?)
>    feature freeze
>
>  1.5-rc1   (December?)
>    all known bugs fixed - ready for testing by users
>
>  1.5:
>    about a month after rc1
>    champagne time
>
>  1.6:
>    Spring 2006
>    other backwards-compatible enhancements
>
>  2.0
>    loosen compatibility requirements / address syntax and API concerns /
>    incremental addition of new syntax and features
>
> ***
>
> More Detail
>
> 1.5-beta
>
> It's unusual for Velocity to release a beta, but I like the idea of freezing 
> all features leaving just a set of obscure bugs.  There's 9 enhancement 
> issues in JIRA that need to be addressed for 1.5.  Most have patches.  All 
> (except for #set null) are straightforward.
>
> Given the significance of this release, I think it would be great to put this 
> out in binary form.
> We can then tell users who need floating point numbers, maps, etc, that they 
> can download a binary instead of checking out the source and compiling.
>
> 1.5-rc1
>
> Fix all bugs in JIRA.  If we do this right this would end up being 1.5.  
> Probably we'll miss something
>
> 1.5
>
> After a fair number of users confirm that 1.5-rc1 has been tested with their 
> applications, then release version 1.5.  Maybe a month after RC1?
>
> 1.6
>
> Sometime in early-mid 2006, roll out a release with other outstanding 
> backwards compatible improvements.  Right now there are 10 issues.
>
> 2.0
>
> We keep talking about a mystical 2.0 release that will release us from the 
> constraints of backwards compatibility.  I suggest this be narrowly focused on
>
> a) cleaning up syntax and API inconsistencies
>
> b) adding new orthagonal features/syntax
>
> Specifically, I'm talking about whitespace processing, commons-logging, maybe 
> some new tags.  We might switch to JDK 1.4 and clean up ORO and other 
> dependencies.  Jython or Groovy support would be cool if someone gets fired 
> up about it.
>
> Regardless, I suggest we avoid the temptation of doing a big rewrite that 
> never finishes.  Think cleanup and incremental changes.  And despite the 
> relaxing of compatibility requirements, I'd suggest that most templates still 
> work with a minimum of changes.
>
> Thoughts?
>
> Thanks, WILL
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to