On 13.09.2018 13:08, Branko Čibej wrote:
> On 13.09.2018 13:01, Stefan Sperling wrote:
>> It should not be too hard to automate the process. The release.py
>> script already has some commands which spit out HTML snippets for
>> the news pages so it might as well be parsing CHANGES and produce
>> HT
On 13.09.2018 17:11, Julian Foad wrote:
> Julian Foad wrote:
>> [...] Are we saying now
>> that they need not be specifically marked if we feel they are pretty
>> safe? If we say that, then marking specific APIs as "experimental" in a
>> regular release signifies only that we consider them more
Julian Foad wrote:
> [...] Are we saying now
> that they need not be specifically marked if we feel they are pretty
> safe? If we say that, then marking specific APIs as "experimental" in a
> regular release signifies only that we consider them more experimental
> (less stable) than others.
>
The 1.11.0-rc1 release artifacts are now available for testing/signing.
Please get the tarballs from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there.
Thanks!
--
- Julian
Branko Čibej wrote:
> Stefan Sperling wrote:
> > How about we provide a linkified version of CHANGES in our
> > release notes HTML pages? [...] based on only the respective
> > release's section of the CHANGES file [...]. For instance, the page
> > http://subversion.apache.org/docs/release-notes/1.
Julian Foad wrote:
> Stefan Sperling wrote:
> > I believe a short note at the top of the file which explains how to
> > resolve these references would be sufficient. Something like this maybe:
> >
> > To view a revision listed in change log entries below, visit:
> > https://svn.apache.org/rXXX
On 13.09.2018 13:01, Stefan Sperling wrote:
> On Thu, Sep 13, 2018 at 11:50:57AM +0100, Julian Foad wrote:
>> Stefan Sperling wrote:
>>> I don't think many people follow these references when reading CHANGES.
>> [...]
>>> I believe a short note at the top of the file which explains how to
>>> resol
On Thu, Sep 13, 2018 at 11:50:57AM +0100, Julian Foad wrote:
> Stefan Sperling wrote:
> > I don't think many people follow these references when reading CHANGES.
> [...]
> > I believe a short note at the top of the file which explains how to
> > resolve these references would be sufficient. Somethi
Stefan Sperling wrote:
> I don't think many people follow these references when reading CHANGES.
[...]
> I believe a short note at the top of the file which explains how to
> resolve these references would be sufficient. Something like this maybe:
>
> To view a revision listed in change log entr
On Thu, Sep 13, 2018 at 10:01:25AM +0100, Julian Foad wrote:
> It seems to me rather poor that readers of our CHANGES file have to manually
> follow references to revision numbers and issue numbers. Examples:
> [[[
> - Server-side bugfixes:
> * svnadmin dump shouldn't canonicalize svn:date (
On Thu, Sep 13, 2018 at 12:00:39PM +0200, Branko Čibej wrote:
> Given all the debate we've had about how to edit and merge the CHANGES
> file on trunk and release branches ... how about only having the change
> log in the wiki, with CHANGES containing only a pointer to the wiki page?
My impression
On 13.09.2018 11:18, Johan Corveleyn wrote:
> On Thu, Sep 13, 2018 at 11:01 AM Julian Foad wrote:
>> It seems to me rather poor that readers of our CHANGES file have to manually
>> follow references to revision numbers and issue numbers. Examples:
>> [[[
>> - Server-side bugfixes:
>> * svna
On Thu, Sep 13, 2018 at 11:01 AM Julian Foad wrote:
>
> It seems to me rather poor that readers of our CHANGES file have to manually
> follow references to revision numbers and issue numbers. Examples:
> [[[
> - Server-side bugfixes:
> * svnadmin dump shouldn't canonicalize svn:date (issue
Markdown seems ubiquitous nowadays. In its raw form it is human readable,
as well as being machine-parsable into HTML / PDF, etc.
Git's README is markdown (https://github.com/git/git/blob/master/README.md)
but the releases notes are still plain text (
https://raw.githubusercontent.com/git/git/mas
It seems to me rather poor that readers of our CHANGES file have to manually
follow references to revision numbers and issue numbers. Examples:
[[[
- Server-side bugfixes:
* svnadmin dump shouldn't canonicalize svn:date (issue #4767)
* 'svnadmin verify --keep-going --quiet' shows an erro
Daniel Shahaf wrote:
> Julian Foad wrote:
>> We recently decided that only APIs released in an LTS release will be
>> subject to our compatibility guarantees. As 1.11 is not an LTS release,
>> the above APIs will not be subject to those guarantees (until they
>> appear in an LTS).
>>
>> Do we n
Daniel Shahaf wrote:
> Julian Foad wrote on Wed, 12 Sep 2018 20:39 +0100:
> > I will plan to release 1.11 on 2018-10-17 which is a Wednesday 5 weeks
> > from today. I have to enter a planned release date in the CHANGES file,
>
> I'm not sure you do, not yet. [...]
Technically you're right about
17 matches
Mail list logo
