Mark, what would the policy dictate if the bug is in a feature that was introduced in 3.x and the feature wasn't in 3.0 and the current release is 3.x+k where k is greater than two - technically 3.x is no longer supported, so does that mean no backporting of the fix and only 3.x+k+1 would get the bug fix (or maybe 3.x+k-1.y in your rare cases)? In this case the user on 3.x would have to upgrade more than two releases to get the big fix even though 3.x may only have been released a few months earlier. I think this is the gist of the original discussion that the EOL policy for 3.x is way too short for more conservative customers.
Maybe the right answer for them is to only use x.0.z releases and not use features introduced in x.y releases. But even then... if they adopt 3.0.z just a month or two before x+1.0 comes out they are back in that same boat that no matter what release they pick it will go EOL within just a few months. -- Jack Krupansky On Thu, Jan 14, 2016 at 11:39 AM, Mark Dewey <milde...@gmail.com> wrote: > Let's do a couple examples: > > 1. Current release: 3.4.0, bug found in 3.1.0 that also exists in > subsequent versions; the bug fix will be ported back to 3.0.x and 3.5.0. > 2. Current release 3.3.0, bug found in 3.3.0; the bug fix will be ported > back to 3.0.x and 3.4.0. In rare cases, a 3.3.1 may also be released > (we've > already seen one example of this). > 3. Current release 3.6.0, bug found in 3.1.0; the bug fix will be ported > back to 3.0.x and 3.7. > > Essentially, any bug fixes will be released in the next minor version and > backported to the 3.0.x branches (unless the feature doesn't exist in 3.0). > We have seen one instance where we released a point version as well, but > that was for a major regression that was discovered almost immediately > after a release. > > On Wed, Jan 13, 2016 at 12:55 PM Maciek Sakrejda <mac...@heroku.com> > wrote: > > > Can anyone chime in here? We're getting ready to run a decent number of > > nodes; we'd like to have a better idea of what to expect with respect to > > patching and upgrading. A clear versioning policy like the one laid out > by > > Postgres would be very helpful. > > > > >
