On Tue, 04 Mar 2014 11:16:41 +0100 martin at v.loewis.de wrote: > > Quoting Nick Coghlan <ncoghlan at gmail.com>: > > > If you don't want to do an rc3 despite the cherry picked changes since > > rc2, then you need to make it easy for people to test the changes > > directly from the release branch. An opaque intermittently updated > > tarball is not acceptable when none of our infrastructure is designed > > to work that way. I was OK with just the tarball when I assumed you > > would an rc3 if non-trivial defects were found in rc2. If that's not > > the case, then we *need* a public mirror of your release clone. > > Another rc or not - I expect to see a 3.4.1 release *really* shortly after > the 3.4.0 release. So except for issues where Python does not work at all, > any glitches that remain in the code can be fixed in the bug fix release. I agree with Martin. At this point, we'd better release 3.4.0 (fixing any critical regressions, but leaving non-critical ones aside), then patiently collect evidence of issues, and fix them in non-rush mode for 3.4.1. Regards Antoine.
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