On Tue, Sep 8, 2009 at 2:06 PM, Ron Mayer<rm...@cheapcomplexdevices.com> wrote: > Andrew Dunstan wrote: >> In any case, I don't accept this analogy. The mechanics of a Linux >> distribution are very different from the mechanics of a project like >> PostgreSQL. The prominent OSS project that seems to me most like ours is >> the Apache HTTP project. > > I'd think that File Systems might be more like postgres - with a shared > obsession about data loss risks, and concerns about compatibility > with any on-disk format changes. I wonder if the ext4 or btrfs > guys use time-based release schedules, or if they'll release when > it's ready. I see the ZFS guys have target dates for completing > features that are still in beta, but also that they change as needed.[1] > [1] http://opensolaris.org/os/project/zfs-crypto/ > > Anyone know how the F/OSS filesystem guys schedule their releases? > > > I agree it's quite different than a distro - which, if I understand > correctly, is mostly a matter of identifying completed and stable > features rather than completing and stabilizing features. > >> I would argue that it would be an major setback for us if we made >> another release without having Hot Standby or whatever we are calling it >> now. I would much rather slip one month or three than ship without it. > > Perhaps if sufficiently interesting features get in outside of > a time-based schedule, an extra release could be made after the > commit fest it gets in? > > If hot-standby + streaming-replication + index_only_scans + > magic-fairy-dust-powered-shared-nothing-clusters all happened > to get in 3 months after a time-based release, it'd be nice to > see it sooner rather than waiting 9 months for a time-based window.
That's somewhat true, but major patches are also more likely to come with bugs. I think we ought to try to time major patches near the beginning of the release cycle, not the end. Indeed, I'd be much more inclined to support a proposal to branch the tree and do an out-of-sequence release just BEFORE committing a bunch of major features rather than just after. Otherwise, PostgreSQL's reputation for being a solid product with solid releases will suffer. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
