From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Fernando Nasser <fnasser(at)redhat(dot)com>, Lee Kindness <lkindness(at)csl(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PQnotifies() in 7.3 broken? |
Date: | 2002-12-12 21:12:36 |
Message-ID: | 5342.1039727556@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> So if a recompile fixes it, increment minor, else major.
Wrong --- if you need a recompile then it's not binary-compatible, so
it should be a major version bump.
> Then we
> normally only do minor-level changes,. and frankly we improve the code
> all during development time and during beta, so it seems pretty abitrary
> when we increment the minor unless we want to increment it many times
> during development, _or_ right before final to ensure that final
> releaase users have the newest version.
I think there is definite value in incrementing the minor version once
at the start of the cycle. Whether we do it at start or end does not
matter to end users, but it *does* help developers, who can then easily
tell whether they are looking at a devel library or the previous
release.
If we make a non-binary-compatible change during a development cycle,
we should then immediately bump the major version number. Leaving it
till the end of the cycle is an excellent recipe for forgetting, as
indeed we just did.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-12-12 21:18:13 | Re: PQnotifies() in 7.3 broken? |
Previous Message | Tom Lane | 2002-12-12 21:08:06 | Creating a zero-column table |