On Sat, Mar 17, 2001 at 08:35:17AM -0800, aahz@panix.com wrote: > Remember that all bugfixes are available as patches off of SourceForge. I'm sorry, Aahz, but that is just plain not true. It's not a little bit not true, it's very not true. A lot of the patches applied are either never submitted to SF (because it's the 'obvious fix' by one of the commiters) or are modified to some extent from thh SF patch proposed. (Often formatting/code style, fairly frequently symbol renaming, and not too infrequently changes in the logic for various reasons.) > > ... that would make 10+ 'releases' of various form in those 6 months. > > Ain't no-one[*] going to check them out for a decent spin, they'll just > > wait for the final version. > That's why I'm making the beta cycle artificially long (I'd even vote > for a two-month minimum). It slows the release pace and -- given the > usually high quality of Python betas -- it encourages people to try them > out. I believe that we *do* need patch betas for system testing. But having a patch release once every 6 months negates the whole purpose of patch releases :) If you are in need of a bugfix, you don't want to wait three months before a bugfix release beta with your specific bug fixed is going to be released, and you don't want to wait two months more for the release to become final. (Note: we're talking people who don't want to use the next feature release beta or current CVS version, so they aren't likely to try a bugfix release beta either.) Bugfix releases should come often-ish, compared to feature releases. But maybe we can get the BDFL to slow the pace of feature releases instead ? Is the 6-month speedway really appropriate if we have a separate bugfix release track ? > > I'm also for starting the maintenance branch right after the real release, > > and start adding bugfixes to it right away, as soon as they show up. Keeping > > up to date on bufixes to the head branch is then as 'simple' as watching > > python-checkins. (Up until the fact a whole subsystem gets rewritten, that > > is :) People should still be able to submit bugfixes for the maintenance > > branch specifically. > That is *precisely* why my original proposal suggested that only the N-1 > release get patch attention, to conserve effort. It is also why I > suggested that patch releases get hooked to feature releases. There is no technical reason to do just N-1. You can branch of as often as you want (in fact, branches never disappear, so if we were building 3.5 ten years from now (and we would still be using CVS <wink GregS>) we could apply a specific patch to the 2.0 maintenance branch and release 2.0.128, if need be.) Keeping too many maintenance branches active does bring the administrative nightmare with it, of course. We can start with just N-1 and see where it goes from there. If significant numbers of people are still using 2.0.5 when 2.2 comes out, we might have to reconsider. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4