Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fvTOv-0000aV-Hq for pgsql-docs@arkaria.postgresql.org; Thu, 30 Aug 2018 20:18:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fvTOu-0006GA-37 for pgsql-docs@arkaria.postgresql.org; Thu, 30 Aug 2018 20:18:44 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fvTLi-0004RG-DA for pgsql-docs@lists.postgresql.org; Thu, 30 Aug 2018 20:15:26 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fvTLd-0004oe-Or for pgsql-docs@lists.postgresql.org; Thu, 30 Aug 2018 20:15:24 +0000 Received: by mail-lf1-x133.google.com with SMTP id g6-v6so8183534lfb.11 for ; Thu, 30 Aug 2018 13:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H9PlKUhTzoS1gO1oV54ZOcJi35gpjCL4V2lHxB0Lz/w=; b=hSuszZXDRVKGPMc2FCkJXLt955wcIQQmtWiwqiTTsf+F6Dm/t6HftZ+/Cwf2mKdwxJ 7a5q3FvteB6cbVYeR1FcJbtoQrME1CCAAzBD8dgOLwv1t9GLhEw6lLwdE++Hne2GDnCu IzLf8gzANH1K8sErk3m14SzUE2dYJBdvNzK0a25sqX6sHDwyeIUuRf8AUSAeo0N6PNmt 9aYTPdMktGd2qNgnLnbkL6NLTdzrvP6hHuHjToesB34cmLRXflyetmA6cLIVkiebh9cj o60uWJh8wHNP+IQSFHAgC0/5/9wYFIYCXkKSVy7fnN1vlD3z0hhTfMEBiCtwapi5i2Pw 1DCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H9PlKUhTzoS1gO1oV54ZOcJi35gpjCL4V2lHxB0Lz/w=; b=uDZA9hWxO6ljJSJquKL9rPSaIkjTatjfNjzABSOSym3S6zXjYfQ1bVgv2GNy+Sw/8d Ld7z5svzVUXd3mUmq+qpblbjIqQDheNJ0BtqdzEDGmSHLZy5xUk/jSeeb4fJJqmehr/G s5uI+amjN10B/rx3xbgWgG0AqbHo1n9QM3P4IEfmtPtPhyLseqStRdLtnItsmWfJ1n05 yVnGGHJf6QUnyHgYCMuhNAADjl76uxt6ld2hw7LdDeeDz6+upwkGnoXPKh83+ybecM3R hB9gcw6mRrGWEQfHYBneEmqwVrApTWeuqP+GWsxrzRy29fOnSSgdCnRBL1/8GDzMy8u6 y3vA== X-Gm-Message-State: APzg51CVgf7l68wsspB24axUZuj9d+froDwARlRPW2CrZVV0hWoRpZSI dZORPFcopOGyeQFR4pJsVvq8yk6ihWfsPiuTSkJ9Hg== X-Google-Smtp-Source: ANB0VdYaO9s3aLmeWtcBnmImNfb9egJnczIjVrQtTvD6aAK/ni11IdOo7ge4Her4ZeGwLO9thQGWNC9xE0u3Wt7WSCI= X-Received: by 2002:a19:1f01:: with SMTP id f1-v6mr8111467lff.42.1535660120144; Thu, 30 Aug 2018 13:15:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:18e4:0:0:0:0:0 with HTTP; Thu, 30 Aug 2018 13:15:19 -0700 (PDT) In-Reply-To: References: <19252.1533509841@sss.pgh.pa.us> From: Magnus Hagander Date: Thu, 30 Aug 2018 22:15:19 +0200 Message-ID: Subject: Re: Release note trimming: another modest proposal To: Peter Eisentraut Cc: Tom Lane , pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000f50ee00574acbb0c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000f50ee00574acbb0c Content-Type: text/plain; charset="UTF-8" On Fri, Aug 10, 2018 at 1:38 AM, Peter Eisentraut < peter.eisentraut@2ndquadrant.com> wrote: > On 06/08/2018 00:57, Tom Lane wrote: > > Anyway, I'd like to propose a compromise position that I don't think > > has been discussed before: let's drop release notes for branches > > that were already EOL when a given branch was released. So for > > example, 9.3 and before would go away from v12, due out next year. > > Working backwards, we'd drop 9.1 and before from v10, giving the 15% > > savings in page count that I showed above. A quick measurement says > > that would also trim the size of the v10 tarball by about 4%, which > > is not a lot maybe but it's noticeable across a lot of downloads. > > Why not go further and just ship the release notes of the current major > version. If you want to look at the release notes of version 11, read > the documentation for version 11. Who reads the documentation of > version 12 to get the release notes of version 11? > +1 for that. At least if we get a generic release notes index up on the website, easy to find. That might also make the process of manually merging release notes back and forth in the release process easier, I assume? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ --000000000000f50ee00574acbb0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 10, 2018 at 1:38 AM, Peter Eisentraut <peter.eisent= raut@2ndquadrant.com> wrote:
On 06/08/2018 00:57, Tom Lane wrote:
> Anyway, I'd like to propose a compromise position that I don't= think
> has been discussed before: let's drop release notes for branches > that were already EOL when a given branch was released.=C2=A0 So for > example, 9.3 and before would go away from v12, due out next year.
> Working backwards, we'd drop 9.1 and before from v10, giving the 1= 5%
> savings in page count that I showed above.=C2=A0 A quick measurement s= ays
> that would also trim the size of the v10 tarball by about 4%, which > is not a lot maybe but it's noticeable across a lot of downloads.<= br>
Why not go further and just ship the release notes of the current ma= jor
version.=C2=A0 If you want to look at the release notes of version 11, read=
the documentation for version 11.=C2=A0 Who reads the documentation of
version 12 to get the release notes of version 11?
+1 for that. At least if we get a generic release notes index u= p on the website, easy to find.

That might also ma= ke the process of manually merging release notes back and forth in the rele= ase process easier, I assume?

--
=C2=A0Magnus Hagander
=C2=A0Me: https://www.hagander.net/
=C2=A0Work: https://www.redpill-linpro= .com/

--000000000000f50ee00574acbb0c--