Julian Foad wrote on Tue, 21 Aug 2018 16:19 +0100:
> However, a process of marking all new APIs as experimental in regular
> releases, and ensuring we review them for LTS releases, might be a good
> way to satisfy both Semantic Versioning and experimental APIs.
+1
Daniel Shahaf wrote on 2018-06-29:
> Julian Foad wrote on Fri, Jun 22, 2018:
> > Another angle on this: I interpret what we are doing as inserting extra
> > mini-feature-releases into the existing cycle, rather than compressing the
> > existing cycle to happen four times faster.
>
> I wonder what
> Julian Foad wrote:
> > > Committed to http://subversion-staging.apache.org/roadmap.html in
> > > http://svn.apache.org/r1835861 [...]
> > >
> > > OK?
> >
> > My thoughts:
> >
> > * should say patch releases are not time-based but ad-hoc (Marcin K.
> > just asked about this on IRC)
> >
> > *
Marcin also suggested we take a look at Mercurial's release schedule Wiki page
for any inspiration we can draw from it:
https://www.mercurial-scm.org/wiki/TimeBasedReleasePlan
- Julian
Julian Foad wrote:
> > Committed to http://subversion-staging.apache.org/roadmap.html in
> > http://svn.apac
Julian Foad wrote:
> > Yes, +1 on this lighter proposal.
>
> Committed to http://subversion-staging.apache.org/roadmap.html in
> http://svn.apache.org/r1835861 [...]
>
> OK?
My thoughts:
* should say patch releases are not time-based but ad-hoc (Marcin K. just asked
about this on IRC)
* shou
Johan Corveleyn wrote on 2018-06-29:
> > [[[
> > Subversions delivers two kinds of stable releases:
> >
> > * Long Term Support (LTS):
> > - release every 2 years; 4 years support; emphasis on stability
> > * standard:
> > - release every 6 months; 6 months support; emphasis on features
On Fri, Jun 29, 2018 at 1:32 PM, Julian Foad wrote:
> Can others approve or comment on this reduced plan please, especially those
> who +1'd the previous statement ( http://svn.apache.org/r1834111 ) which I
> now think was too onerous?
>
> Stefan Sperling wrote:
>> I would prefer having just the
Julian Foad wrote on Fri, Jun 22, 2018 at 14:26:53 +0100:
> Another angle on this: I interpret what we are doing as inserting extra
> mini-feature-releases into the existing cycle, rather than compressing the
> existing cycle to happen four times faster.
I wonder what our API compatibility promise
On 29.06.2018 13:32, Julian Foad wrote:
> Can others approve or comment on this reduced plan please, especially those
> who +1'd the previous statement ( http://svn.apache.org/r1834111 ) which I
> now think was too onerous?
>
> Stefan Sperling wrote:
>> I would prefer having just the minimum requ
Can others approve or comment on this reduced plan please, especially those who
+1'd the previous statement ( http://svn.apache.org/r1834111 ) which I now
think was too onerous?
Stefan Sperling wrote:
> I would prefer having just the minimum requirements we are going
> to fullfill written down.
On Mon, Jun 25, 2018 at 05:54:14PM +0100, Julian Foad wrote:
> Julian Foad wrote:
> > Forget about overlap periods, for a moment. Then there will be usually 3
> > supported lines (after a standard release) and sometimes 2 [...]
>
> I am wondering if we have been mis-thinking the support plans. Wh
Julian Foad wrote:
> Forget about overlap periods, for a moment. Then there will be usually 3
> supported lines (after a standard release) and sometimes 2 [...]
I am wondering if we have been mis-thinking the support plans. Why should we
want to backport feature fixes and improvements for 6 mont
Daniel Shahaf wrote on 2018-06-25:
> Julian Foad wrote:
>> [...] then the support period of one or more of the older release lines
>> will simply expire before we get around to it [...]
>
> Suppose a security issue is found that affects "1.9 and all later
> versions", don't we (implicitly) promis
Julian Foad wrote on Mon, 25 Jun 2018 11:31 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote on Fri, 22 Jun 2018 14:26 +0100:
> >> That is why I think we should keep the support period for 1.9 as one
> >> release (until 1.10) for general fixes plus 2 years (being roughly the
> >> same as one o
Daniel Shahaf wrote:
> Julian Foad wrote on Fri, 22 Jun 2018 14:26 +0100:
>> That is why I think we should keep the support period for 1.9 as one
>> release (until 1.10) for general fixes plus 2 years (being roughly the
>> same as one old release cycle period that would have been expected) for
>
Julian Foad wrote on Fri, 22 Jun 2018 14:26 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote on Fri, Jun 22, 2018 at 12:27:21 +0100:
> > > Done in http://svn.apache.org/r1834111,
> > > "Publish our new 6-month standard and 2-year LTS release schedule."
> >
> > In practical terms, we have now pr
Daniel Shahaf wrote:
> Julian Foad wrote on Fri, Jun 22, 2018 at 12:27:21 +0100:
> > Done in http://svn.apache.org/r1834111,
> > "Publish our new 6-month standard and 2-year LTS release schedule."
>
> In practical terms, we have now promised to release 1.11.0 around October, so
> we should start t
Julian Foad wrote on Fri, Jun 22, 2018 at 12:27:21 +0100:
> Julian Foad wrote on 2018-05-20:
> > I suggest our next step should be updating the Subversion web pages to
> > state (clearly) this new policy. We should not yet delete the statements
> > about the old policy.
> >
> > Does anyone want
Julian Foad wrote on 2018-05-20:
> I suggest our next step should be updating the Subversion web pages to
> state (clearly) this new policy. We should not yet delete the statements
> about the old policy.
>
> Does anyone want to volunteer to do that? If not, I will.
Done in http://svn.apache.o
Michael Osipov wrote:
>I would like to insist on the proper and simple wording of such a
>statement especially for non-English speaking natives.
I agree. I am sorry the way I first wrote it was not clear enough.
I suggest our next step should be updating the Subversion web pages to state
(clear
Am 2018-05-20 um 13:53 schrieb Daniel Shahaf:
LTS release:
* full backports for at least 2 years, and at least until the next LTS
release
* security/corruption fixes for at least 4 years, and at least until the
next-but-one LTS release
Sorry, no. No one can plan with the words "at least
> > LTS release:
> > * full backports for at least 2 years, and at least until the next LTS
> > release
> > * security/corruption fixes for at least 4 years, and at least until the
> > next-but-one LTS release
>
> Sorry, no. No one can plan with the words "at least". This isn't a
> guarante
Stefan Sperling wrote:
On Fri, May 18, 2018 at 02:29:25PM +0100, Julian Foad wrote:
> Branch for stabilization 4 months after the last release (which was in
2018-04), so:
>
> * Branch in 2018-08
> * Aim to release in 2018-10
Wouldn't we also have to adjust our backporting guidelines if we
On 5/18/2018 4:27 PM, Julian Foad wrote:
Stefan Sperling wrote on 2018-05-18:
On Fri, May 18, 2018 at 02:54:03PM +0100, Julian Foad wrote:
LTS release:
* full backports for at least 2 years, and at least until the next LTS
release
* security/corruption fixes for at least 4 years, and at
Stefan Sperling wrote on 2018-05-18:
> On Fri, May 18, 2018 at 02:54:03PM +0100, Julian Foad wrote:
> > LTS release:
> > * full backports for at least 2 years, and at least until the next LTS
> > release
> > * security/corruption fixes for at least 4 years, and at least until the
> > next-but
Julian Foad wrote on Fri, 18 May 2018 14:54 +0100:
> standard release:
> * full backports at least until the next standard release
> * security/corruption fixes at least until the next-but-one standard release
Nitpick, but: s/until the next standard release/until the next release/
(whether the
On Fri, May 18, 2018 at 02:54:03PM +0100, Julian Foad wrote:
> Stefan Sperling wrote:
> > On Fri, May 18, 2018 at 02:29:25PM +0100, Julian Foad wrote:
> > > Branch for stabilization 4 months after the last release (which was in
> > > 2018-04), so:
> > >
> > > * Branch in 2018-08
> > > * Aim t
Stefan Sperling wrote:
> On Fri, May 18, 2018 at 02:29:25PM +0100, Julian Foad wrote:
> > Branch for stabilization 4 months after the last release (which was in
> > 2018-04), so:
> >
> > * Branch in 2018-08
> > * Aim to release in 2018-10
>
> Wouldn't we also have to adjust our backporting g
On Fri, May 18, 2018 at 02:29:25PM +0100, Julian Foad wrote:
> Branch for stabilization 4 months after the last release (which was in
> 2018-04), so:
>
> * Branch in 2018-08
> * Aim to release in 2018-10
Wouldn't we also have to adjust our backporting guidelines if we
did this? Would 1.10 on
Johan Corveleyn wrote:
> I think we need to aim for a much sooner 1.11 release. And I'd like us
> to agree on some intended planning / timing. I know it's easy to talk
> about it, and much more difficult to actually *do it*. But first
> things first, what are our intentions?
Yes, let's agree a pla
On Fri, May 18, 2018 at 9:46 AM, Stefan Sperling wrote:
[ snip discussion about bumping the minimum JDK requirements ... (was
Re: JDK 10 removal of javah)]
> ... when
> Subversion 1.11 will be released in probably 2 to 3 years from now?
I think we need to aim for a much sooner 1.11 release. And
31 matches
Mail list logo
