[Guido] > > I have one concern: an awful large number of patches went into 2.2.1 > > in a very short time, and I worry a bit that one release candidate may > > not be sufficient to make sure that we really didn't introduce any new > > bugs. [Michael] > I think the time argument may be a red herring; I'm not sure there are > so many people checking the branch out that it really makes any > difference. I was more thinking that you've been working so hard that your error rate might have gone up. :-) > But I agree there have been a lot of changes, and some pretty subtle > ones. That's the real reason to be cautious. > > Perhaps we should consider to issue a second release candidate, > > or at least have a waiting time longer than 1 week between rc and > > final. (I'd be happy with 2 weeks.) > > How about releasing 2.2.1c1, waiting two weeks and then deciding > whether we need a c2? In an ideal world, changing the candidate > release into a final release would just be a matter of changing > version numbers. Sounds good, but that means two full weeks of willpower exercises. Or did you think you wouldn't get any pressure to add more last-minute fixes to rc2? :-) > Two weeks gets us pretty near Easter; I may not be around so much for > the Easter weekend. I don't mind about the exact timing, and assuming there are no disasters, not much would need to be done. (Off-topic: shouldn't the new date/time contain an easterdate() method? :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
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