Re: Feature Freeze date for 8.4
От | Tom Lane |
---|---|
Тема | Re: Feature Freeze date for 8.4 |
Дата | |
Msg-id | 6052.1193182940@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Feature Freeze date for 8.4 (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Feature Freeze date for 8.4
Re: Feature Freeze date for 8.4 |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: > Plus, for the developers and other people who really need to be > bleeding-edge, this new plan would result in less-unstable snapshots every > 2 months with defined feature sets which someone who wanted to run them at > their own risk could. Which would result in more bug reports, earlier, > for us (and lots of forwarding the canned > "milestone-releases-are-not-stable" canned e-mail). Hmm, I was not envisioning that we'd produce any sort of "release" corresponding to these checkpoints. I see it only as a a way to (a) discipline ourselves to not let patches go unreviewed/uncommitted for long periods, and (b) encourage developers to submit relatively small patches rather than enormous six-months-of-work ones. Since there are always bugs, and we're certainly not going to schedule a round of formal beta testing right after each commit-fest, I should think that tarballs made right after a commit-fest would be particularly unlikely to be good candidates for non-developer use. (Actually, it might be the case that a CVS snap from just *before* a commit-fest would be the most stable development-cycle code, since there'd have been time to shake out bugs committed in the previous fest... but we're even less likely to do beta testing on that.) regards, tom lane
В списке pgsql-hackers по дате отправления: