You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by st...@apache.org on 2021/02/10 20:39:23 UTC
svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Author: stsp
Date: Wed Feb 10 20:39:22 2021
New Revision: 1886396
URL: http://svn.apache.org/viewvc?rev=1886396&view=rev
Log:
site/publish: Merge from staging area.
Modified:
subversion/site/publish/ (props changed)
subversion/site/publish/doap.rdf
subversion/site/publish/docs/release-notes/release-history.html
subversion/site/publish/download.html
Propchange: subversion/site/publish/
------------------------------------------------------------------------------
Merged /subversion/site/staging:r1886391-1886395
Modified: subversion/site/publish/doap.rdf
URL: http://svn.apache.org/viewvc/subversion/site/publish/doap.rdf?rev=1886396&r1=1886395&r2=1886396&view=diff
==============================================================================
--- subversion/site/publish/doap.rdf (original)
+++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021
@@ -22,7 +22,7 @@
limitations under the License.
-->
<Project rdf:about="http://subversion.apache.org/">
- <created>2010-12-28</created>
+ <created>2021-02-10</created>
<license rdf:resource="http://usefulinc.com/doap/licenses/asl20" />
<name>Apache Subversion</name>
<homepage rdf:resource="http://subversion.apache.org/" />
@@ -37,15 +37,15 @@
<release>
<Version>
<name>Current 1.14 LTS release</name>
- <created>2020-05-27</created>
- <revision>1.14.0</revision>
+ <created>2021-02-10</created>
+ <revision>1.14.1</revision>
</Version>
</release>
<release>
<Version>
<name>Current 1.10 LTS release</name>
- <created>2019-07-24</created>
- <revision>1.10.6</revision>
+ <created>2021-02-10</created>
+ <revision>1.10.7</revision>
</Version>
</release>
<repository>
Modified: subversion/site/publish/docs/release-notes/release-history.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/release-history.html?rev=1886396&r1=1886395&r2=1886396&view=diff
==============================================================================
--- subversion/site/publish/docs/release-notes/release-history.html (original)
+++ subversion/site/publish/docs/release-notes/release-history.html Wed Feb 10 20:39:22 2021
@@ -31,6 +31,12 @@ Subversion 2.0.</p>
<ul>
<li>
+ <b>Subversion 1.14.1</b> (Wednesday, 10 February 2021): Bugfix/security release.
+ </li>
+ <li>
+ <b>Subversion 1.10.7</b> (Wednesday, 10 February 2021): Bugfix/security release.
+ </li>
+ <li>
<b>Subversion 1.14.0</b> (Wednesday, 27 May 2020): Feature and bugfix release, see the <a href="/docs/release-notes/1.14.html">release notes</a>.
</li>
<li>
Modified: subversion/site/publish/download.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/download.html?rev=1886396&r1=1886395&r2=1886396&view=diff
==============================================================================
--- subversion/site/publish/download.html (original)
+++ subversion/site/publish/download.html Wed Feb 10 20:39:22 2021
@@ -102,7 +102,7 @@ Other mirrors:
title="Link to this section">¶</a>
</h3>
-<p style="font-size: 150%; text-align: center;">Apache Subversion 1.14.0 LTS</p>
+<p style="font-size: 150%; text-align: center;">Apache Subversion 1.14.1 LTS</p>
<table class="centered">
<tr>
<th>File</th>
@@ -111,20 +111,20 @@ Other mirrors:
<th>PGP Public Keys</th>
</tr>
<tr>
- <td><a href="[preferred]subversion/subversion-1.14.0.tar.bz2">subversion-1.14.0.tar.bz2</a></td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.0.tar.bz2.sha512">SHA-512</a>]</td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.0.tar.bz2.asc">PGP signatures</a>]</td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.0.KEYS">PGP keyring</a>]</td>
+ <td><a href="[preferred]subversion/subversion-1.14.1.tar.bz2">subversion-1.14.1.tar.bz2</a></td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.1.tar.bz2.sha512">SHA-512</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.1.tar.bz2.asc">PGP signatures</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.1.KEYS">PGP keyring</a>]</td>
</tr><tr>
- <td><a href="[preferred]subversion/subversion-1.14.0.tar.gz">subversion-1.14.0.tar.gz</a></td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.0.tar.gz.sha512">SHA-512</a>]</td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.0.tar.gz.asc">PGP signatures</a>]</td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.0.KEYS">PGP keyring</a>]</td>
+ <td><a href="[preferred]subversion/subversion-1.14.1.tar.gz">subversion-1.14.1.tar.gz</a></td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.1.tar.gz.sha512">SHA-512</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.1.tar.gz.asc">PGP signatures</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.1.KEYS">PGP keyring</a>]</td>
</tr><tr>
- <td><a href="[preferred]subversion/subversion-1.14.0.zip">subversion-1.14.0.zip</a></td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.0.zip.sha512">SHA-512</a>]</td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.0.zip.asc">PGP signatures</a>]</td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.0.KEYS">PGP keyring</a>]</td>
+ <td><a href="[preferred]subversion/subversion-1.14.1.zip">subversion-1.14.1.zip</a></td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.1.zip.sha512">SHA-512</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.1.zip.asc">PGP signatures</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.14.1.KEYS">PGP keyring</a>]</td>
</tr>
</table>
@@ -136,31 +136,29 @@ Other mirrors:
title="Link to this section">¶</a>
</h3>
-<p style="font-size: 150%; text-align: center;">Apache Subversion 1.10.6 LTS</p>
+<p style="font-size: 150%; text-align: center;">Apache Subversion 1.10.7 LTS</p>
<table class="centered">
<tr>
<th>File</th>
<th>Checksum (SHA512)</th>
<th>Signatures</th>
+ <th>PGP Public Keys</th>
</tr>
<tr>
- <td><a href="[preferred]subversion/subversion-1.10.6.tar.bz2">subversion-1.10.6.tar.bz2</a></td>
- <!-- The sha512 line does not have a class="checksum" since the link needn't
- be rendered in monospace. -->
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.6.tar.bz2.sha512">SHA-512</a>]</td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.6.tar.bz2.asc">PGP</a>]</td>
+ <td><a href="[preferred]subversion/subversion-1.10.7.tar.bz2">subversion-1.10.7.tar.bz2</a></td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.7.tar.bz2.sha512">SHA-512</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.7.tar.bz2.asc">PGP signatures</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.7.KEYS">PGP keyring</a>]</td>
</tr><tr>
- <td><a href="[preferred]subversion/subversion-1.10.6.tar.gz">subversion-1.10.6.tar.gz</a></td>
- <!-- The sha512 line does not have a class="checksum" since the link needn't
- be rendered in monospace. -->
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.6.tar.gz.sha512">SHA-512</a>]</td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.6.tar.gz.asc">PGP</a>]</td>
+ <td><a href="[preferred]subversion/subversion-1.10.7.tar.gz">subversion-1.10.7.tar.gz</a></td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.7.tar.gz.sha512">SHA-512</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.7.tar.gz.asc">PGP signatures</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.7.KEYS">PGP keyring</a>]</td>
</tr><tr>
- <td><a href="[preferred]subversion/subversion-1.10.6.zip">subversion-1.10.6.zip</a></td>
- <!-- The sha512 line does not have a class="checksum" since the link needn't
- be rendered in monospace. -->
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.6.zip.sha512">SHA-512</a>]</td>
- <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.6.zip.asc">PGP</a>]</td>
+ <td><a href="[preferred]subversion/subversion-1.10.7.zip">subversion-1.10.7.zip</a></td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.7.zip.sha512">SHA-512</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.7.zip.asc">PGP signatures</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-1.10.7.KEYS">PGP keyring</a>]</td>
</tr>
</table>
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Sahlberg <da...@gmail.com>.
Den ons 17 feb. 2021 19:42Daniel Shahaf <d....@daniel.shahaf.name> skrev:
> Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100:
> > Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf <
> d.s@daniel.shahaf.name>:
> > > Is it worthwhile to automate this step? doap.rdf changes rarely enough
> > > that we needn't bother with "edit part of a file" logic; we can just
> > > regenerate the entire file and «svnmucc put» it into place, with a
> > > comment indicating it's a generated file.
> >
> > The doap.rdf contain references to two separate releases (at least
> > right now) and when running release.py you are working on one release
> > at a time. So we can't just have a template and add the current
> > release number, we also need to know the other release (which could
> > have been a year ago or the same day).
>
> Well, yes, and «release.py clean-dist» already has logic to determine
> the other release's version number.
>
> > To automate "edit part of file", we would need to search for the same
> > major.minor and replace with current relase, but when there is a new
> > minor (1.15..) we would have to edit manually anyway.
>
> I don't think so.
>
> We could generate subversion-%(version)s.rdf-excerpt files, drop them in
> dist/, and then use clean_dist()-like logic to cat the right subset of
> them, adding a fixed header and trailer. This way, we wouldn't need to
> splice lines out of and into the file, and we wouldn't need to special-case
> the first release of a minor line or the EOLing of a minor line in the
> logic.
>
> > It's a balance between the amount of work done by RM, the downside of
> > having different processes for new minor and new patch release and the
> > work to code to automate. I'm leaning towards having it as it is, but
> > I would listen to Stefan's opinion (since he did the most recent RM).
>
> By and large, agreed, but see above for the details.
>
All this sounds good. However I'm not fluent in Python and even though
learning is on my to-do, it is not high enough right now so I'll leave it
to someone else.
Kind regards
Daniel Sahlberg
>
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Sahlberg <da...@gmail.com>.
Den ons 17 feb. 2021 19:42Daniel Shahaf <d....@daniel.shahaf.name> skrev:
> Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100:
> > Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf <
> d.s@daniel.shahaf.name>:
> > > Is it worthwhile to automate this step? doap.rdf changes rarely enough
> > > that we needn't bother with "edit part of a file" logic; we can just
> > > regenerate the entire file and «svnmucc put» it into place, with a
> > > comment indicating it's a generated file.
> >
> > The doap.rdf contain references to two separate releases (at least
> > right now) and when running release.py you are working on one release
> > at a time. So we can't just have a template and add the current
> > release number, we also need to know the other release (which could
> > have been a year ago or the same day).
>
> Well, yes, and «release.py clean-dist» already has logic to determine
> the other release's version number.
>
> > To automate "edit part of file", we would need to search for the same
> > major.minor and replace with current relase, but when there is a new
> > minor (1.15..) we would have to edit manually anyway.
>
> I don't think so.
>
> We could generate subversion-%(version)s.rdf-excerpt files, drop them in
> dist/, and then use clean_dist()-like logic to cat the right subset of
> them, adding a fixed header and trailer. This way, we wouldn't need to
> splice lines out of and into the file, and we wouldn't need to special-case
> the first release of a minor line or the EOLing of a minor line in the
> logic.
>
> > It's a balance between the amount of work done by RM, the downside of
> > having different processes for new minor and new patch release and the
> > work to code to automate. I'm leaning towards having it as it is, but
> > I would listen to Stefan's opinion (since he did the most recent RM).
>
> By and large, agreed, but see above for the details.
>
All this sounds good. However I'm not fluent in Python and even though
learning is on my to-do, it is not high enough right now so I'll leave it
to someone else.
Kind regards
Daniel Sahlberg
>
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100:
> Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf <d....@daniel.shahaf.name>:
> > Is it worthwhile to automate this step? doap.rdf changes rarely enough
> > that we needn't bother with "edit part of a file" logic; we can just
> > regenerate the entire file and «svnmucc put» it into place, with a
> > comment indicating it's a generated file.
>
> The doap.rdf contain references to two separate releases (at least
> right now) and when running release.py you are working on one release
> at a time. So we can't just have a template and add the current
> release number, we also need to know the other release (which could
> have been a year ago or the same day).
Well, yes, and «release.py clean-dist» already has logic to determine
the other release's version number.
> To automate "edit part of file", we would need to search for the same
> major.minor and replace with current relase, but when there is a new
> minor (1.15..) we would have to edit manually anyway.
I don't think so.
We could generate subversion-%(version)s.rdf-excerpt files, drop them in
dist/, and then use clean_dist()-like logic to cat the right subset of
them, adding a fixed header and trailer. This way, we wouldn't need to
splice lines out of and into the file, and we wouldn't need to special-case
the first release of a minor line or the EOLing of a minor line in the
logic.
> It's a balance between the amount of work done by RM, the downside of
> having different processes for new minor and new patch release and the
> work to code to automate. I'm leaning towards having it as it is, but
> I would listen to Stefan's opinion (since he did the most recent RM).
By and large, agreed, but see above for the details.
Cheers,
Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100:
> Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf <d....@daniel.shahaf.name>:
> > Is it worthwhile to automate this step? doap.rdf changes rarely enough
> > that we needn't bother with "edit part of a file" logic; we can just
> > regenerate the entire file and «svnmucc put» it into place, with a
> > comment indicating it's a generated file.
>
> The doap.rdf contain references to two separate releases (at least
> right now) and when running release.py you are working on one release
> at a time. So we can't just have a template and add the current
> release number, we also need to know the other release (which could
> have been a year ago or the same day).
Well, yes, and «release.py clean-dist» already has logic to determine
the other release's version number.
> To automate "edit part of file", we would need to search for the same
> major.minor and replace with current relase, but when there is a new
> minor (1.15..) we would have to edit manually anyway.
I don't think so.
We could generate subversion-%(version)s.rdf-excerpt files, drop them in
dist/, and then use clean_dist()-like logic to cat the right subset of
them, adding a fixed header and trailer. This way, we wouldn't need to
splice lines out of and into the file, and we wouldn't need to special-case
the first release of a minor line or the EOLing of a minor line in the
logic.
> It's a balance between the amount of work done by RM, the downside of
> having different processes for new minor and new patch release and the
> work to code to automate. I'm leaning towards having it as it is, but
> I would listen to Stefan's opinion (since he did the most recent RM).
By and large, agreed, but see above for the details.
Cheers,
Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf <d....@daniel.shahaf.name>:
> Is it worthwhile to automate this step? doap.rdf changes rarely enough
> that we needn't bother with "edit part of a file" logic; we can just
> regenerate the entire file and «svnmucc put» it into place, with a
> comment indicating it's a generated file.
The doap.rdf contain references to two separate releases (at least
right now) and when running release.py you are working on one release
at a time. So we can't just have a template and add the current
release number, we also need to know the other release (which could
have been a year ago or the same day).
To automate "edit part of file", we would need to search for the same
major.minor and replace with current relase, but when there is a new
minor (1.15..) we would have to edit manually anyway.
It's a balance between the amount of work done by RM, the downside of
having different processes for new minor and new patch release and the
work to code to automate. I'm leaning towards having it as it is, but
I would listen to Stefan's opinion (since he did the most recent RM).
Kind regards,
Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf <d....@daniel.shahaf.name>:
> Is it worthwhile to automate this step? doap.rdf changes rarely enough
> that we needn't bother with "edit part of a file" logic; we can just
> regenerate the entire file and «svnmucc put» it into place, with a
> comment indicating it's a generated file.
The doap.rdf contain references to two separate releases (at least
right now) and when running release.py you are working on one release
at a time. So we can't just have a template and add the current
release number, we also need to know the other release (which could
have been a year ago or the same day).
To automate "edit part of file", we would need to search for the same
major.minor and replace with current relase, but when there is a new
minor (1.15..) we would have to edit manually anyway.
It's a balance between the amount of work done by RM, the downside of
having different processes for new minor and new patch release and the
work to code to automate. I'm leaning towards having it as it is, but
I would listen to Stefan's opinion (since he did the most recent RM).
Kind regards,
Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Sahlberg wrote on Tue, 16 Feb 2021 13:05 +00:00:
> Den tis 16 feb. 2021 kl 13:15 skrev Stefan Sperling <st...@elego.de>:
> > On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote:
> > > What do you think about this?
> > > [[[
> > > List the new release on ^/subversion/site/publish/doap.rdf
> > > There should be a <release> section for each supported minor release
> > > with the <created> and <revision> being updated to the current release
> > > date and patch release number.
> > > Do not change anything else in the file (in particular the <created>
> > > under <Project> is the date when the Subversion project was created).
> > > ]]]
> >
> > That is crystal clear and should avoid mistakes going forward. Thank you!
>
> r1886589
Is it worthwhile to automate this step? doap.rdf changes rarely enough
that we needn't bother with "edit part of a file" logic; we can just
regenerate the entire file and «svnmucc put» it into place, with a
comment indicating it's a generated file.
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Sahlberg wrote on Tue, 16 Feb 2021 13:05 +00:00:
> Den tis 16 feb. 2021 kl 13:15 skrev Stefan Sperling <st...@elego.de>:
> > On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote:
> > > What do you think about this?
> > > [[[
> > > List the new release on ^/subversion/site/publish/doap.rdf
> > > There should be a <release> section for each supported minor release
> > > with the <created> and <revision> being updated to the current release
> > > date and patch release number.
> > > Do not change anything else in the file (in particular the <created>
> > > under <Project> is the date when the Subversion project was created).
> > > ]]]
> >
> > That is crystal clear and should avoid mistakes going forward. Thank you!
>
> r1886589
Is it worthwhile to automate this step? doap.rdf changes rarely enough
that we needn't bother with "edit part of a file" logic; we can just
regenerate the entire file and «svnmucc put» it into place, with a
comment indicating it's a generated file.
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 16 feb. 2021 kl 13:15 skrev Stefan Sperling <st...@elego.de>:
>
> On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote:
> > Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling <st...@elego.de>:
> > > On Mon, Feb 15, 2021 at 07:46:08PM +0000, Daniel Shahaf wrote:
> > > > The entity referred to by the <Project/> tag wasn't created in 2021. So,
> > > > I think the hunk is incorrect… but so was the original value, which referred to
> > > > the _file_'s creation date (r1053461), rather than to the date Subversion was
> > > > founded (2000), the date it was accepted into the Incubator, or the date it was
> > > > promoted to TLP.
> >
> > Should this be reverted, maybe even back to the proper creation date
> > (2000-02-29)?
>
> Yes please. I'm sorry for my mistake.
> Could you handle that as well while committing the change below?
r1886588
I've done this as a separate commit because I think we should merge
this to publish quite quickly. I'll leave it until tomorrow in case
someone has objections. The other changes can wait for a little bit
more discussion.
>
> > What do you think about this?
> > [[[
> > List the new release on ^/subversion/site/publish/doap.rdf
> > There should be a <release> section for each supported minor release
> > with the <created> and <revision> being updated to the current release
> > date and patch release number.
> > Do not change anything else in the file (in particular the <created>
> > under <Project> is the date when the Subversion project was created).
> > ]]]
>
> That is crystal clear and should avoid mistakes going forward. Thank you!
r1886589
/Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 16 feb. 2021 kl 13:15 skrev Stefan Sperling <st...@elego.de>:
>
> On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote:
> > Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling <st...@elego.de>:
> > > On Mon, Feb 15, 2021 at 07:46:08PM +0000, Daniel Shahaf wrote:
> > > > The entity referred to by the <Project/> tag wasn't created in 2021. So,
> > > > I think the hunk is incorrect… but so was the original value, which referred to
> > > > the _file_'s creation date (r1053461), rather than to the date Subversion was
> > > > founded (2000), the date it was accepted into the Incubator, or the date it was
> > > > promoted to TLP.
> >
> > Should this be reverted, maybe even back to the proper creation date
> > (2000-02-29)?
>
> Yes please. I'm sorry for my mistake.
> Could you handle that as well while committing the change below?
r1886588
I've done this as a separate commit because I think we should merge
this to publish quite quickly. I'll leave it until tomorrow in case
someone has objections. The other changes can wait for a little bit
more discussion.
>
> > What do you think about this?
> > [[[
> > List the new release on ^/subversion/site/publish/doap.rdf
> > There should be a <release> section for each supported minor release
> > with the <created> and <revision> being updated to the current release
> > date and patch release number.
> > Do not change anything else in the file (in particular the <created>
> > under <Project> is the date when the Subversion project was created).
> > ]]]
>
> That is crystal clear and should avoid mistakes going forward. Thank you!
r1886589
/Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote:
> Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling <st...@elego.de>:
> > On Mon, Feb 15, 2021 at 07:46:08PM +0000, Daniel Shahaf wrote:
> > > The entity referred to by the <Project/> tag wasn't created in 2021. So,
> > > I think the hunk is incorrect… but so was the original value, which referred to
> > > the _file_'s creation date (r1053461), rather than to the date Subversion was
> > > founded (2000), the date it was accepted into the Incubator, or the date it was
> > > promoted to TLP.
>
> Should this be reverted, maybe even back to the proper creation date
> (2000-02-29)?
Yes please. I'm sorry for my mistake.
Could you handle that as well while committing the change below?
> What do you think about this?
> [[[
> List the new release on ^/subversion/site/publish/doap.rdf
> There should be a <release> section for each supported minor release
> with the <created> and <revision> being updated to the current release
> date and patch release number.
> Do not change anything else in the file (in particular the <created>
> under <Project> is the date when the Subversion project was created).
> ]]]
That is crystal clear and should avoid mistakes going forward. Thank you!
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 16, 2021 at 01:05:32PM +0100, Daniel Sahlberg wrote:
> Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling <st...@elego.de>:
> > On Mon, Feb 15, 2021 at 07:46:08PM +0000, Daniel Shahaf wrote:
> > > The entity referred to by the <Project/> tag wasn't created in 2021. So,
> > > I think the hunk is incorrect… but so was the original value, which referred to
> > > the _file_'s creation date (r1053461), rather than to the date Subversion was
> > > founded (2000), the date it was accepted into the Incubator, or the date it was
> > > promoted to TLP.
>
> Should this be reverted, maybe even back to the proper creation date
> (2000-02-29)?
Yes please. I'm sorry for my mistake.
Could you handle that as well while committing the change below?
> What do you think about this?
> [[[
> List the new release on ^/subversion/site/publish/doap.rdf
> There should be a <release> section for each supported minor release
> with the <created> and <revision> being updated to the current release
> date and patch release number.
> Do not change anything else in the file (in particular the <created>
> under <Project> is the date when the Subversion project was created).
> ]]]
That is crystal clear and should avoid mistakes going forward. Thank you!
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling <st...@elego.de>:
>
> On Mon, Feb 15, 2021 at 07:46:08PM +0000, Daniel Shahaf wrote:
> > stsp@apache.org wrote on Wed, Feb 10, 2021 at 20:39:23 -0000:
> > > Author: stsp
> > > Date: Wed Feb 10 20:39:22 2021
> > > New Revision: 1886396
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1886396&view=rev
> > > Log:
> > > site/publish: Merge from staging area.
> >
> > For future reference, this commit should have used the "less than 24 hours ago" syntax:
> >
> > % cd site/publish
> > % grep -R -h -9 YYYY | vipe
> > <!-- A parameter in the form '?update=YYYYMMDDhhmm' may
> > be appended to 'download.cgi' to only offer mirrors that have
> > synced after the specified date. We update it after a security
> > release when the email announcement is less than 24 hours after
> > the upload to /dist/release, in order to prevent offering mirrors
> > that don't carry the just-released artifacts. -->
> > %
> >
> > More below.
> >
> > > +++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021
> > > @@ -22,7 +22,7 @@
> > > limitations under the License.
> > > -->
> > > <Project rdf:about="http://subversion.apache.org/">
> > > - <created>2010-12-28</created>
> > > + <created>2021-02-10</created>
> >
> > Huh?
> >
> > Quoting http://usefulinc.com/ns/doap:
> >
> > > > <rdf:Property rdf:about="http://usefulinc.com/ns/doap#created">
> > > > <rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />
> > > > <rdfs:label xml:lang="en">created</rdfs:label>
> > > > <rdfs:comment xml:lang="en">Date when something was created, in YYYY-MM-DD form. e.g. 2004-04-05</rdfs:comment>
> > > > ⋮
> > > > </rdf:Property>
> >
> > The entity referred to by the <Project/> tag wasn't created in 2021. So,
> > I think the hunk is incorrect… but so was the original value, which referred to
> > the _file_'s creation date (r1053461), rather than to the date Subversion was
> > founded (2000), the date it was accepted into the Incubator, or the date it was
> > promoted to TLP.
Should this be reverted, maybe even back to the proper creation date
(2000-02-29)?
> >
> > Thanks for RMing,
> >
> > Daniel
> >
>
> Thanks for checking.
>
> I think in both of these cases it would have helped to have more specific
> instructions for how to update these files in our release manager's manual
> of the community guide.
What do you think about this?
[[[
List the new release on ^/subversion/site/publish/doap.rdf
There should be a <release> section for each supported minor release
with the <created> and <revision> being updated to the current release
date and patch release number.
Do not change anything else in the file (in particular the <created>
under <Project> is the date when the Subversion project was created).
]]]
Kind regards,
Daniel Sahlberg
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 16 feb. 2021 kl 11:34 skrev Stefan Sperling <st...@elego.de>:
>
> On Mon, Feb 15, 2021 at 07:46:08PM +0000, Daniel Shahaf wrote:
> > stsp@apache.org wrote on Wed, Feb 10, 2021 at 20:39:23 -0000:
> > > Author: stsp
> > > Date: Wed Feb 10 20:39:22 2021
> > > New Revision: 1886396
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1886396&view=rev
> > > Log:
> > > site/publish: Merge from staging area.
> >
> > For future reference, this commit should have used the "less than 24 hours ago" syntax:
> >
> > % cd site/publish
> > % grep -R -h -9 YYYY | vipe
> > <!-- A parameter in the form '?update=YYYYMMDDhhmm' may
> > be appended to 'download.cgi' to only offer mirrors that have
> > synced after the specified date. We update it after a security
> > release when the email announcement is less than 24 hours after
> > the upload to /dist/release, in order to prevent offering mirrors
> > that don't carry the just-released artifacts. -->
> > %
> >
> > More below.
> >
> > > +++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021
> > > @@ -22,7 +22,7 @@
> > > limitations under the License.
> > > -->
> > > <Project rdf:about="http://subversion.apache.org/">
> > > - <created>2010-12-28</created>
> > > + <created>2021-02-10</created>
> >
> > Huh?
> >
> > Quoting http://usefulinc.com/ns/doap:
> >
> > > > <rdf:Property rdf:about="http://usefulinc.com/ns/doap#created">
> > > > <rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />
> > > > <rdfs:label xml:lang="en">created</rdfs:label>
> > > > <rdfs:comment xml:lang="en">Date when something was created, in YYYY-MM-DD form. e.g. 2004-04-05</rdfs:comment>
> > > > ⋮
> > > > </rdf:Property>
> >
> > The entity referred to by the <Project/> tag wasn't created in 2021. So,
> > I think the hunk is incorrect… but so was the original value, which referred to
> > the _file_'s creation date (r1053461), rather than to the date Subversion was
> > founded (2000), the date it was accepted into the Incubator, or the date it was
> > promoted to TLP.
Should this be reverted, maybe even back to the proper creation date
(2000-02-29)?
> >
> > Thanks for RMing,
> >
> > Daniel
> >
>
> Thanks for checking.
>
> I think in both of these cases it would have helped to have more specific
> instructions for how to update these files in our release manager's manual
> of the community guide.
What do you think about this?
[[[
List the new release on ^/subversion/site/publish/doap.rdf
There should be a <release> section for each supported minor release
with the <created> and <revision> being updated to the current release
date and patch release number.
Do not change anything else in the file (in particular the <created>
under <Project> is the date when the Subversion project was created).
]]]
Kind regards,
Daniel Sahlberg
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Feb 15, 2021 at 07:46:08PM +0000, Daniel Shahaf wrote:
> stsp@apache.org wrote on Wed, Feb 10, 2021 at 20:39:23 -0000:
> > Author: stsp
> > Date: Wed Feb 10 20:39:22 2021
> > New Revision: 1886396
> >
> > URL: http://svn.apache.org/viewvc?rev=1886396&view=rev
> > Log:
> > site/publish: Merge from staging area.
>
> For future reference, this commit should have used the "less than 24 hours ago" syntax:
>
> % cd site/publish
> % grep -R -h -9 YYYY | vipe
> <!-- A parameter in the form '?update=YYYYMMDDhhmm' may
> be appended to 'download.cgi' to only offer mirrors that have
> synced after the specified date. We update it after a security
> release when the email announcement is less than 24 hours after
> the upload to /dist/release, in order to prevent offering mirrors
> that don't carry the just-released artifacts. -->
> %
>
> More below.
>
> > +++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021
> > @@ -22,7 +22,7 @@
> > limitations under the License.
> > -->
> > <Project rdf:about="http://subversion.apache.org/">
> > - <created>2010-12-28</created>
> > + <created>2021-02-10</created>
>
> Huh?
>
> Quoting http://usefulinc.com/ns/doap:
>
> > > <rdf:Property rdf:about="http://usefulinc.com/ns/doap#created">
> > > <rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />
> > > <rdfs:label xml:lang="en">created</rdfs:label>
> > > <rdfs:comment xml:lang="en">Date when something was created, in YYYY-MM-DD form. e.g. 2004-04-05</rdfs:comment>
> > > ⋮
> > > </rdf:Property>
>
> The entity referred to by the <Project/> tag wasn't created in 2021. So,
> I think the hunk is incorrect… but so was the original value, which referred to
> the _file_'s creation date (r1053461), rather than to the date Subversion was
> founded (2000), the date it was accepted into the Incubator, or the date it was
> promoted to TLP.
>
> Thanks for RMing,
>
> Daniel
>
Thanks for checking.
I think in both of these cases it would have helped to have more specific
instructions for how to update these files in our release manager's manual
of the community guide.
Thanks,
Stefan
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Feb 15, 2021 at 07:46:08PM +0000, Daniel Shahaf wrote:
> stsp@apache.org wrote on Wed, Feb 10, 2021 at 20:39:23 -0000:
> > Author: stsp
> > Date: Wed Feb 10 20:39:22 2021
> > New Revision: 1886396
> >
> > URL: http://svn.apache.org/viewvc?rev=1886396&view=rev
> > Log:
> > site/publish: Merge from staging area.
>
> For future reference, this commit should have used the "less than 24 hours ago" syntax:
>
> % cd site/publish
> % grep -R -h -9 YYYY | vipe
> <!-- A parameter in the form '?update=YYYYMMDDhhmm' may
> be appended to 'download.cgi' to only offer mirrors that have
> synced after the specified date. We update it after a security
> release when the email announcement is less than 24 hours after
> the upload to /dist/release, in order to prevent offering mirrors
> that don't carry the just-released artifacts. -->
> %
>
> More below.
>
> > +++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021
> > @@ -22,7 +22,7 @@
> > limitations under the License.
> > -->
> > <Project rdf:about="http://subversion.apache.org/">
> > - <created>2010-12-28</created>
> > + <created>2021-02-10</created>
>
> Huh?
>
> Quoting http://usefulinc.com/ns/doap:
>
> > > <rdf:Property rdf:about="http://usefulinc.com/ns/doap#created">
> > > <rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />
> > > <rdfs:label xml:lang="en">created</rdfs:label>
> > > <rdfs:comment xml:lang="en">Date when something was created, in YYYY-MM-DD form. e.g. 2004-04-05</rdfs:comment>
> > > ⋮
> > > </rdf:Property>
>
> The entity referred to by the <Project/> tag wasn't created in 2021. So,
> I think the hunk is incorrect… but so was the original value, which referred to
> the _file_'s creation date (r1053461), rather than to the date Subversion was
> founded (2000), the date it was accepted into the Incubator, or the date it was
> promoted to TLP.
>
> Thanks for RMing,
>
> Daniel
>
Thanks for checking.
I think in both of these cases it would have helped to have more specific
instructions for how to update these files in our release manager's manual
of the community guide.
Thanks,
Stefan
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
stsp@apache.org wrote on Wed, Feb 10, 2021 at 20:39:23 -0000:
> Author: stsp
> Date: Wed Feb 10 20:39:22 2021
> New Revision: 1886396
>
> URL: http://svn.apache.org/viewvc?rev=1886396&view=rev
> Log:
> site/publish: Merge from staging area.
For future reference, this commit should have used the "less than 24 hours ago" syntax:
% cd site/publish
% grep -R -h -9 YYYY | vipe
<!-- A parameter in the form '?update=YYYYMMDDhhmm' may
be appended to 'download.cgi' to only offer mirrors that have
synced after the specified date. We update it after a security
release when the email announcement is less than 24 hours after
the upload to /dist/release, in order to prevent offering mirrors
that don't carry the just-released artifacts. -->
%
More below.
> +++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021
> @@ -22,7 +22,7 @@
> limitations under the License.
> -->
> <Project rdf:about="http://subversion.apache.org/">
> - <created>2010-12-28</created>
> + <created>2021-02-10</created>
Huh?
Quoting http://usefulinc.com/ns/doap:
> > <rdf:Property rdf:about="http://usefulinc.com/ns/doap#created">
> > <rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />
> > <rdfs:label xml:lang="en">created</rdfs:label>
> > <rdfs:comment xml:lang="en">Date when something was created, in YYYY-MM-DD form. e.g. 2004-04-05</rdfs:comment>
> > ⋮
> > </rdf:Property>
The entity referred to by the <Project/> tag wasn't created in 2021. So,
I think the hunk is incorrect… but so was the original value, which referred to
the _file_'s creation date (r1053461), rather than to the date Subversion was
founded (2000), the date it was accepted into the Incubator, or the date it was
promoted to TLP.
Thanks for RMing,
Daniel
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf
docs/release-notes/release-history.html download.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
stsp@apache.org wrote on Wed, Feb 10, 2021 at 20:39:23 -0000:
> Author: stsp
> Date: Wed Feb 10 20:39:22 2021
> New Revision: 1886396
>
> URL: http://svn.apache.org/viewvc?rev=1886396&view=rev
> Log:
> site/publish: Merge from staging area.
For future reference, this commit should have used the "less than 24 hours ago" syntax:
% cd site/publish
% grep -R -h -9 YYYY | vipe
<!-- A parameter in the form '?update=YYYYMMDDhhmm' may
be appended to 'download.cgi' to only offer mirrors that have
synced after the specified date. We update it after a security
release when the email announcement is less than 24 hours after
the upload to /dist/release, in order to prevent offering mirrors
that don't carry the just-released artifacts. -->
%
More below.
> +++ subversion/site/publish/doap.rdf Wed Feb 10 20:39:22 2021
> @@ -22,7 +22,7 @@
> limitations under the License.
> -->
> <Project rdf:about="http://subversion.apache.org/">
> - <created>2010-12-28</created>
> + <created>2021-02-10</created>
Huh?
Quoting http://usefulinc.com/ns/doap:
> > <rdf:Property rdf:about="http://usefulinc.com/ns/doap#created">
> > <rdfs:isDefinedBy rdf:resource="http://usefulinc.com/ns/doap#" />
> > <rdfs:label xml:lang="en">created</rdfs:label>
> > <rdfs:comment xml:lang="en">Date when something was created, in YYYY-MM-DD form. e.g. 2004-04-05</rdfs:comment>
> > ⋮
> > </rdf:Property>
The entity referred to by the <Project/> tag wasn't created in 2021. So,
I think the hunk is incorrect… but so was the original value, which referred to
the _file_'s creation date (r1053461), rather than to the date Subversion was
founded (2000), the date it was accepted into the Incubator, or the date it was
promoted to TLP.
Thanks for RMing,
Daniel