The structural changes starting in 4.0 and continuing in 4.1 and beyond are to make it easier to add features without breaking backwards compatibility. Less API == less to maintain compatibility with.
I've also been thinking about adding some annotations to mark interfaces and classes as internal. Referencing internal types from non-internal types should be marked as a warning. This will allow us a fine grained approach to marking types as internal, not to be used and abused, short of a non-backwards compatible package restructuring. Maven 2 seems to be coming together; I suspect that early on, HiveMind and Tapestry will build under Maven 2. This will make frequent releases much less critical, since building latest and greatest from SVN will simply require a single command. I'm also finally swayed on a more Apache style of release numbering and releasing, where the "quality" of a release (beta, final, etc.) is voted on AFTER the release has been out and about. So, say, Tapestry 4.1.6 may be the first beta, and Tapestry 4.1.10 may be the final release. 4.1.11 would be alpha or beta, and eventually there would be a, say, 4.1.20 that would be the new stable 4.1 branch release. This is how most Apache projects, including Struts and the web server operate. On 12/20/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: > I'm thinking more of a 4-6 month release cycle, like other OS software > projects do. It's a good balance between the two. > > As for me, I'd prefer a more continuous release cycle, specially because > of the regressions. I prefer a gradual breaking change that I can absorb > in several release cycles, than justifying a large migration - which is > of course, full of dangerous pitfalls. The other problem is that a > 1-year / 3 quarters release schedule easily goes into a full 2 year > schedule or more. How long did you guys thought "Tapestry 3.1" was going > to take when you started it? And now we're looking forward to even more > breaking changes. So... strap yourselves for a 3 year release cycle! > Certainly not a good way to go with full competition from JSF and > related frameworks! > > Now, what limits you from just grabbing 4.2 and ignoring the 4.1 release? > > "release early, release often" doesn't mean "upgrade early, upgrade > often" ;). > > -- > Ing. Leonardo Quijano Vincenzi > DTQ Software > > > Patrick Casey wrote: > > Eeek! Maybe I'm weird on this one, but I'd much rather have a small > > number of big releases than a continuous upgrade cycle. > > > > Every time I change a core library, it's a regression testing > > nightmare. Even if nothing at all breaks, I still have to go back and ensure > > that fact. I can deal with changing tapestry jars every year or so and not > > feel bad about it, but anything significantly faster than than (like monthly > > or quarterly releases) would make my life much harder, not easier. > > > > The only way I could see that sort of release cycle working is if > > Howard could *guarantee* that the monthly releases never, ever, broke > > backward compatibility. That way I could skip the regression tests, but > > frankly that's a huge pile of turd for Howard to have to shovel as it's not > > really practical. I can't think of a single OS project that can make such a > > guarantee (even hibernate breaks something of mine virtually every time they > > release). > > > > --- Pat > > > > > > --------------------------------------------------------------------- > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
