Hi Mike, Thanks for bringing up this discussion. It's a good one to have.
On 1/31/06, Michael Schneider <[EMAIL PROTECTED]> wrote: > It seems like there are 2 big releases being thought about > > 0.9 - bugs in trac (less widget, less ????) > > 1.0 - widget Not exactly. 0.9 is slated to include widgets. People have been beating on widgets for a few weeks now, and they generally work well for people. The API refinements proposed by Michele Cella and David Bernard seem like a good way to clean things up a bit now that people have been using these more. I'm going to look at those closely today. > Couple of observations: > - there is still alot of tickets against 0.9 > - there are many tickets against 0.9 > - 1.0 implies some stabliity > - most people are running TurboGears out of SVN to pick up the new > features > > Proposal: > - change to fixed-length time-boxed iterations ~2-4 weeks?? > - change thought pattern from 0.9 and 1.0 to: .9, .91 (4 weeks > later, .92 (4 weeks after that), ..... 1.0 when API's stabilize. The 0.9 release cycle has definitely been longer than I wanted. That's my fault for not trimming it back soon. But, with that water under the bridge, I wanted the new APIs to get some measure of stability before making a release. Right now, running from the svn trunk gives people an expectation that things will be changing all over the place. Once there's a release (even if it's labeled alpha), the barrier to entry is lower and people will expect some measure of stability. The intention is for 0.9.x to solidify (and debug) all of the new stuff introduced in 0.9. Once that's done, it will become 1.0. So, we're definitely not looking at the same kind of release path between 0.9 and 1.0 that we've seen between 0.8 and 0.9. The widgets API refinements and Simon Belak's new error handler are really the last big, potentially breaking things that I'm planning for 0.9. Once those are in, I'm comfortable with making a 0.9.0a1 release. Yes, there are bugs, but people will certainly expect *that* from an alpha. At least the APIs will be stable. > ... rinse, repeat until widgets stabilize > > 1.0 - Stable API's for > - Widgets ?? > - ??? > Experimental APIs for: > - ??? I'm really expecting fairly stable APIs between 0.9 and 1.0. Yes, there will be new ideas and improvements, but it seems like the APIs are good enough for people to get things done. > I guess what I am proposing is: > - timebox iterations (even if few changes occur) > - for each release, identify: > stable API's (if they exist :-) > experimental API's I wonder what the best way to identify experimental APIs is? I worry about just throwing something like that in the docs, because it's easy to miss that. Sure, someone needs to refer to the docs to use something, but maybe they're just taking a recipe they found on the wiki or something. Maybe experimental things should need to be explicitly turned on... (By the way, I'm thinking specifically about experimental APIs that are in releases. Nothing like that is necessary for svn versions, of course.) > TurboGears is making excellent progress. I really like the direction > it is going in. It is just a personal opinion, but a fixed timebox for > iterations would be very useful. > > Variable scope is fine with me. I am not looking for commitments to > scope. Time boxed releases would add value to TurboGears. I would amend that to be "frequent releases would add value to TurboGears". In open source, the pace of development is quite variable, so it's harder to peg a date as being a good balance of things to release. The TurboGears core has a good collection of unit tests, but some parts of it do not have as many automated tests as I'd like. That also makes it harder to just build a release at arbitrary times. Going forward, I would like to see frequent releases, and I think that doing the following will allow us to comfortably do that: * have a standard mechanism to enable experimental features * more tests * bring the docs up to speed and keep them up to date as APIs and features become stable > Proposal for a plan (please change where this is wrong): > - Show stopper tickets for 0.9 would need to be tagged > - A 0.91 release would need to be created in trac > - all non show-stoppers would need to be moved to 0.91 release > - An 0.91 SVN branch would need to be created (or 0.9 bugfix branch > would need to be created) > - head would move to 0.91, showstoppers would be fixed in 0.9 branch > - swarm over the show stoppers in the 0.9 release branch > > > The above approach and $3.75 will buy a highly caffinated drink. The > above are just suggestions ment to kick off a discussion on a release > plan. > > Please pardon me if a release plan already exists, I looked at the > site, but missed it. My eyes aren't as good as they used to be. Nope. There's nothing up there now. Let me get the widget and error handling stuff together, and then we'll start in on a more tangible 0.9. Kevin
