Let's switch to time-based releases

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Let's switch to time-based releases

Johan Corveleyn-3
At the hackathon last week we (Stefan Hett, Stefan Fuhrmann, Julian,
Bert and I) discussed how we could get releases out faster. We
exchanged ideas of how we could do "time-based releases", i.e. to
agree on a fixed schedule of doing releases, not waiting for
particular features or bugfixes (except in exceptional circumstances),
and just start the release train on the agreed date with whatever is
on trunk at that time.

I know this has been discussed before, but it was never made reality.
On last week's hackathon we also didn't come to a full consensus on
various details. But I think we should simply work out those details,
hopefully come to some compromise, and if so, JFD it.

One of the problems with creating 1.x releases more often is how many
of those branches to maintain with backports, trying to satisfy both
users wanting new features more quickly, and enterprises desiring
stability and long term support. One way to address this is to
designate certain releases as "LTS" (long term support) releases,
which we'll maintain longer with backports.

Proposal
-----
(1) Start a new 1.x release cycle every 6 months.

    If we branch off 1.10 this week, we could say: 1.11 will branch
end of May, and 1.12 end of November 2018. "Starting release cycle"
means: branching, releasing an rc1, and starting the four-week soak.
Missing the boat with some desired feature is not a disaster, it gets
in 6 months later.


(2) Call one release every 2 years a Long Term Support (LTS) release.

    Say 1.10 becomes an LTS release, the next LTS release will be 1.14
(end of November 2019).


(3) We backport regular fixes to the last 1.x release and the last LTS
release, and security fixes to the last two LTS releases.

    Say 1.12 is just released, and we fix a user-reported bug on
trunk, we backport it to 1.12, to 1.10 (LTS). If we fix a security
issue on trunk, we backport it to 1.12, 1.10 (LTS) and 1.9 (which
we'll call LTS by convention). That means one extra backport to test
compared to nowadays. Though the last 1.x should really be close
behind trunk. Can we manage that?


(4) Features that are already exposed but aren't ready yet should be
shielded with feature toggles, ifdefs, ... to make sure trunk is
almost always in a releasable state (especially close to the branch
point).
-----


We would of course have to go in detail through our community guide
[1] to figure out the details and rewrite the "Releases" chapter.
Apart from that this mainly requires a RM driving it.

Several big projects use time-based releases these days. For instance,
as of this year, Java has switched to it too, with a similar frequency
(6 month release cycles for new features, LTS releases every 3 years)
[2].

Also, our own community guide suggests "every 6 months" as a soft
schedule [3]. We just need to make that a hard schedule and be less
flexible with the timing, but more flexible with what gets in :-).


[1] http://subversion.apache.org/docs/community-guide/releasing.html

[2] https://mreinhold.org/blog/forward-faster

[3] http://subversion.apache.org/docs/community-guide/releasing.html#release-branches
, third paragraph: "The time at which a new release branch needs to be
created is fuzzy at best. Generally, we have a soft schedule of
releasing a new minor version every 6 months. So, approximately 4
months after the previous minor release is a good time to start
proposing a branch. But remember that this is flexible, depending on
what features are being developed."

--
Johan
Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Branko Čibej
On 27.11.2017 14:52, Johan Corveleyn wrote:
> I know this has been discussed before, but it was never made reality.
> On last week's hackathon we also didn't come to a full consensus on
> various details. But I think we should simply work out those details,
> hopefully come to some compromise, and if so, JFD it.

It has been discussed before and for a while we even did it this way.
The problem is that we're again at the point where we have to find a
reluctant volunteer to RM any release we want to make. So ...

"There's no 'we' in Team" :p  Some individual has to step up and do
this. The sort of release train you describe needs someone to drive it,
to whit, a "permanent" release manager. No amount of documentation and
schedules and good intentions will make this happen all by itself.

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Evgeny Kotkov
Branko Čibej <[hidden email]> writes:

>> I know this has been discussed before, but it was never made reality.
>> On last week's hackathon we also didn't come to a full consensus on
>> various details. But I think we should simply work out those details,
>> hopefully come to some compromise, and if so, JFD it.
>
> It has been discussed before and for a while we even did it this way.
> The problem is that we're again at the point where we have to find a
> reluctant volunteer to RM any release we want to make. So ...
>
> "There's no 'we' in Team" :p  Some individual has to step up and do
> this. The sort of release train you describe needs someone to drive it,
> to whit, a "permanent" release manager. No amount of documentation and
> schedules and good intentions will make this happen all by itself.

I concur that the time-based releases most likely won't happen just based
on the agreement, and that there has to be a person driving them.

Perhaps, we could try this approach by finding a volunteer responsible for
RM-ing the 1.11 release — for example, right after 1.10 is released.


Regards,
Evgeny Kotkov
Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Stefan
On 28/11/2017 14:03, Evgeny Kotkov wrote:

> Branko Čibej <[hidden email]> writes:
>
>>> I know this has been discussed before, but it was never made reality.
>>> On last week's hackathon we also didn't come to a full consensus on
>>> various details. But I think we should simply work out those details,
>>> hopefully come to some compromise, and if so, JFD it.
>> It has been discussed before and for a while we even did it this way.
>> The problem is that we're again at the point where we have to find a
>> reluctant volunteer to RM any release we want to make. So ...
>>
>> "There's no 'we' in Team" :p  Some individual has to step up and do
>> this. The sort of release train you describe needs someone to drive it,
>> to whit, a "permanent" release manager. No amount of documentation and
>> schedules and good intentions will make this happen all by itself.
> I concur that the time-based releases most likely won't happen just based
> on the agreement, and that there has to be a person driving them.
>
> Perhaps, we could try this approach by finding a volunteer responsible for
> RM-ing the 1.11 release — for example, right after 1.10 is released.
>
The principle idea as layed out in your initial post sounds fine with
me. But as Evgeny and Brane already pointed out, this requires a
dedicated person who's driving things. So if you (or anybody else
stepping up) is driving this, I'm all for giving this a try and will
also review my signing procedure to speed things up for signing releases
faster.

FWIW: I think the details still need to get refactored a bit, but this
is something which can also be done at the time it becomes apparent.
Namely I'm thinking here that the release process might still require a
few weeks buffer time before shipping a new release and this should be
accounted for in the release roadmap (f.e. branch of a new release every
6 months with the release of that version happening around 1-2 months
later (time for signing and possibly having one or two RCs as it
happened with the 1.10 alpha builds for instance)). For this to not have
a rippling effect on following release, that buffer time should not
impact the time the next release is branched of, of course.

I'm also a bit worried about the acceptance of faster releases (i.e.
once every 6 months). Maybe we'd simply send out a mail to maintainers
polling for which time line they'd prefer (i.e. 6, 9, 12, 24 months for
new releases)? Just for us to get some idea on what those people who'd
be directly impacted by our decision would think about before we are
making a call?

Regards,
Stefan



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Branko Čibej
On 28.11.2017 15:01, Stefan wrote:
> I'm also a bit worried about the acceptance of faster releases (i.e.
> once every 6 months). Maybe we'd simply send out a mail to maintainers
> polling for which time line they'd prefer (i.e. 6, 9, 12, 24 months for
> new releases)? Just for us to get some idea on what those people who'd
> be directly impacted by our decision would think about before we are
> making a call?

That depends a lot on how we handle client (working copy!) compatibility
in future. Breaking the WC every 6 months is not acceptable; people will
simply not adopt newer versions of the client if we do that.

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Stefan
On 28/11/2017 16:16, Branko Čibej wrote:

> On 28.11.2017 15:01, Stefan wrote:
>> I'm also a bit worried about the acceptance of faster releases (i.e.
>> once every 6 months). Maybe we'd simply send out a mail to maintainers
>> polling for which time line they'd prefer (i.e. 6, 9, 12, 24 months for
>> new releases)? Just for us to get some idea on what those people who'd
>> be directly impacted by our decision would think about before we are
>> making a call?
> That depends a lot on how we handle client (working copy!) compatibility
> in future. Breaking the WC every 6 months is not acceptable; people will
> simply not adopt newer versions of the client if we do that.
>
> -- Brane

Are you referring to breaking the possibility for users to go back to
older clients, if they run into problems with newer versions and their
WC having already been upgraded? If so, personally I won't see this as a
strong concern. Or am I missing your point?

But even if so, for users it's completely up to them to decide whether
they want to upgrade to a later version (or skip one or the other). So
even in the case where we'd raise the WC format in each build, I don't
quite see the implications this would have in the decision for or
against time-based releases.

I'm more concerned about the case where users rely on more than a single
client to work with (for example a common combination on Windows would
be TSVN+VisualSVN) and these products would use different release cycles.
Example: VisualSVN decides that a 6-month release update is too much for
them and therefore only release LTS-based releases. This would then
prevent TSVN users from upgrading to TSVN versions other than the
LTS-release. If TSVN however would decide not to support LTS-releases
and only always release the latest version, then we'd be kind of screwed.

To clarify: I'm not arguing against moving to time-based releases. I'm
just not sure whether the 6-month period won't be too short in our case
and we'd better be off with a 9-12 period.

Regards,
Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Branko Čibej
On 28.11.2017 20:23, Stefan wrote:

> On 28/11/2017 16:16, Branko Čibej wrote:
>> On 28.11.2017 15:01, Stefan wrote:
>>> I'm also a bit worried about the acceptance of faster releases (i.e.
>>> once every 6 months). Maybe we'd simply send out a mail to maintainers
>>> polling for which time line they'd prefer (i.e. 6, 9, 12, 24 months for
>>> new releases)? Just for us to get some idea on what those people who'd
>>> be directly impacted by our decision would think about before we are
>>> making a call?
>> That depends a lot on how we handle client (working copy!) compatibility
>> in future. Breaking the WC every 6 months is not acceptable; people will
>> simply not adopt newer versions of the client if we do that.
>>
>> -- Brane
> Are you referring to breaking the possibility for users to go back to
> older clients, if they run into problems with newer versions and their
> WC having already been upgraded? If so, personally I won't see this as a
> strong concern. Or am I missing your point?

This is exactly the point. People have to use different tools that
support different SVN client versions. Every time we break WC
compatibility we make life hell for users who cannot upgrade all their
(development and other) tools for one reason or another. This is not an
imaginary problem, we've heard lots of complaints over the years about that.

> But even if so, for users it's completely up to them to decide whether
> they want to upgrade to a later version (or skip one or the other).

No, it's not. "Users" are not just people like you and me who use the
command-line client, maybe TSVN, vc-svn.el in Emacs etc. They're also
people who use custom integrated toolsets from multiple vendors who, you
can bet, will not change their release time-line just because one small
part of their solution could be upgraded.

> I'm more concerned about the case where users rely on more than a single
> client to work with (for example a common combination on Windows would
> be TSVN+VisualSVN) and these products would use different release cycles.

TSVN and VisualSVN are *trivial* examples. I'm talking about toolsets
where version control is maybe 5% of the functionality, or not even that.


The solution, of course, is to support multiple WC versions in the
client. :)

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Stefan
On 28/11/2017 22:34, Branko Čibej wrote:

> On 28.11.2017 20:23, Stefan wrote:
>> On 28/11/2017 16:16, Branko Čibej wrote:
>>> On 28.11.2017 15:01, Stefan wrote:
>>>> I'm also a bit worried about the acceptance of faster releases (i.e.
>>>> once every 6 months). Maybe we'd simply send out a mail to maintainers
>>>> polling for which time line they'd prefer (i.e. 6, 9, 12, 24 months for
>>>> new releases)? Just for us to get some idea on what those people who'd
>>>> be directly impacted by our decision would think about before we are
>>>> making a call?
>>> That depends a lot on how we handle client (working copy!) compatibility
>>> in future. Breaking the WC every 6 months is not acceptable; people will
>>> simply not adopt newer versions of the client if we do that.
>>>
>>> -- Brane
>> Are you referring to breaking the possibility for users to go back to
>> older clients, if they run into problems with newer versions and their
>> WC having already been upgraded? If so, personally I won't see this as a
>> strong concern. Or am I missing your point?
> This is exactly the point. People have to use different tools that
> support different SVN client versions. Every time we break WC
> compatibility we make life hell for users who cannot upgrade all their
> (development and other) tools for one reason or another. This is not an
> imaginary problem, we've heard lots of complaints over the years about that.
>
>> But even if so, for users it's completely up to them to decide whether
>> they want to upgrade to a later version (or skip one or the other).
> No, it's not. "Users" are not just people like you and me who use the
> command-line client, maybe TSVN, vc-svn.el in Emacs etc. They're also
> people who use custom integrated toolsets from multiple vendors who, you
> can bet, will not change their release time-line just because one small
> part of their solution could be upgraded.
>
>> I'm more concerned about the case where users rely on more than a single
>> client to work with (for example a common combination on Windows would
>> be TSVN+VisualSVN) and these products would use different release cycles.
> TSVN and VisualSVN are *trivial* examples. I'm talking about toolsets
> where version control is maybe 5% of the functionality, or not even that.
>
>
> The solution, of course, is to support multiple WC versions in the
> client. :)
>
> -- Brane
>
Thanks for taking the time to explain your point. :-)

I still think that these type of products/tools will very likely stick
with the LTS version of SVN and/or provide LTS versions themselves. So
for them, I take it almost nothing would change for the time being.
Certainly they will take exactly the point you made into consideration
and hence are likely to conclude too this is one of the biggest
arguments for them to only provide LTS-based releases.

The aim as far as the talks during the hackathon went suggested that we
primarily target the "casual" user like you and me as the target
audience for the releases available at shorter intervals. I guess the
advantages of the shorter interval are quite obvious and aren't really
in question here (just to give some headlines here: better/faster test
coverage of new versions; faster iterations of new features; self-set
deadlines for integrations; etc.).

But of course having the multi-WC-version-support in 1.11 would mitigate
this concern altogether. :-)

Regards,
Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Branko Čibej
On 28.11.2017 23:25, Stefan wrote:

> On 28/11/2017 22:34, Branko Čibej wrote:
>> On 28.11.2017 20:23, Stefan wrote:
>>> On 28/11/2017 16:16, Branko Čibej wrote:
>>>> On 28.11.2017 15:01, Stefan wrote:
>>>>> I'm also a bit worried about the acceptance of faster releases (i.e.
>>>>> once every 6 months). Maybe we'd simply send out a mail to maintainers
>>>>> polling for which time line they'd prefer (i.e. 6, 9, 12, 24 months for
>>>>> new releases)? Just for us to get some idea on what those people who'd
>>>>> be directly impacted by our decision would think about before we are
>>>>> making a call?
>>>> That depends a lot on how we handle client (working copy!) compatibility
>>>> in future. Breaking the WC every 6 months is not acceptable; people will
>>>> simply not adopt newer versions of the client if we do that.
>>>>
>>>> -- Brane
>>> Are you referring to breaking the possibility for users to go back to
>>> older clients, if they run into problems with newer versions and their
>>> WC having already been upgraded? If so, personally I won't see this as a
>>> strong concern. Or am I missing your point?
>> This is exactly the point. People have to use different tools that
>> support different SVN client versions. Every time we break WC
>> compatibility we make life hell for users who cannot upgrade all their
>> (development and other) tools for one reason or another. This is not an
>> imaginary problem, we've heard lots of complaints over the years about that.
>>
>>> But even if so, for users it's completely up to them to decide whether
>>> they want to upgrade to a later version (or skip one or the other).
>> No, it's not. "Users" are not just people like you and me who use the
>> command-line client, maybe TSVN, vc-svn.el in Emacs etc. They're also
>> people who use custom integrated toolsets from multiple vendors who, you
>> can bet, will not change their release time-line just because one small
>> part of their solution could be upgraded.
>>
>>> I'm more concerned about the case where users rely on more than a single
>>> client to work with (for example a common combination on Windows would
>>> be TSVN+VisualSVN) and these products would use different release cycles.
>> TSVN and VisualSVN are *trivial* examples. I'm talking about toolsets
>> where version control is maybe 5% of the functionality, or not even that.
>>
>>
>> The solution, of course, is to support multiple WC versions in the
>> client. :)
>>
>> -- Brane
>>
> Thanks for taking the time to explain your point. :-)
>
> I still think that these type of products/tools will very likely stick
> with the LTS version of SVN and/or provide LTS versions themselves. So
> for them, I take it almost nothing would change for the time being.
> Certainly they will take exactly the point you made into consideration
> and hence are likely to conclude too this is one of the biggest
> arguments for them to only provide LTS-based releases.
>
> The aim as far as the talks during the hackathon went suggested that we
> primarily target the "casual" user like you and me as the target
> audience for the releases available at shorter intervals. I guess the
> advantages of the shorter interval are quite obvious and aren't really
> in question here (just to give some headlines here: better/faster test
> coverage of new versions; faster iterations of new features; self-set
> deadlines for integrations; etc.).

Oh, I'm not against the idea of having more regular releases and the
rest of the points in the proposal. Just pointing out things we'll want
to be aware of. (And hinting to RM volunteers to get their act together,
heh heh.)

> But of course having the multi-WC-version-support in 1.11 would mitigate
> this concern altogether. :-)

I started working on that, then (predictably) ran out of time ... the
starting point is on the better-pristines branch. I have every intention
of taking that up as soon as I have some free time, famous last words.

In the meantime, it appears that 1.8, 1.9 and 1.10 will all use the same
WC format (Julian? I hope stashes don't shatter that dream). So we're
pretty well covered in that respect. For now.

-- Brane
Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Julian Foad-5
Branko Čibej wrote:
> In the meantime, it appears that 1.8, 1.9 and 1.10 will all use the same
> WC format (Julian? I hope stashes don't shatter that dream).

That's correct.

- Julian


> So we're
> pretty well covered in that respect. For now.
>
> -- Brane
Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Johan Corveleyn-3
Great! I gather from the reactions in this thread that we have
consensus on the principle, we "just" need to do it :-). And figure
out some details.

- WC multiple format support: we're okay for now (1.8 - 1.10 have the
same format), but for 1.11 it would be good if we can make
better-pristines happen (go Brane! :-).

- Frequency: should we aim for 6 months, or 9, 12, ... for the "fast
releases" (and "long term support" releases, each a couple of years
apart)? I'd stick with my initial proposal: 6 month release cycle, and
designate one as an LTS release every 2 years, of which we support one
fully, and one more with only security fixes.

If any of our packagers / distributors / integrators has some feedback
here, that'd be most welcome.

--
Johan
Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Branko Čibej
On 01.12.2017 13:16, Johan Corveleyn wrote:
> Great! I gather from the reactions in this thread that we have
> consensus on the principle, we "just" need to do it :-). And figure
> out some details.

Will that be Subversion 18.04 Anticlimactic Albatross?


-- Brane
Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Jacek Materna
6 month
2 year LTS

On Fri, Dec 1, 2017 at 7:38 AM, Branko Čibej <[hidden email]> wrote:
On 01.12.2017 13:16, Johan Corveleyn wrote:
> Great! I gather from the reactions in this thread that we have
> consensus on the principle, we "just" need to do it :-). And figure
> out some details.

Will that be Subversion 18.04 Anticlimactic Albatross?


-- Brane



--

Jacek Materna
Chief Technology Officer

Assembla
+1 210 410 7661
Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Nathan Hartman
In reply to this post by Branko Čibej
On Dec 1, 2017, at 5:38 AM, Branko Čibej <[hidden email]> wrote:
>
>> On 01.12.2017 13:16, Johan Corveleyn wrote:
>> Great! I gather from the reactions in this thread that we have
>> consensus on the principle, we "just" need to do it :-). And figure
>> out some details.
>
> Will that be Subversion 18.04 Anticlimactic Albatross?

Please, please, DON'T do names like that!!!

Reply | Threaded
Open this post in threaded view
|

Re: Let's switch to time-based releases

Johan Corveleyn-3
On Fri, Dec 1, 2017 at 7:13 PM, Nathan Hartman <[hidden email]> wrote:

> On Dec 1, 2017, at 5:38 AM, Branko Čibej <[hidden email]> wrote:
>>
>>> On 01.12.2017 13:16, Johan Corveleyn wrote:
>>> Great! I gather from the reactions in this thread that we have
>>> consensus on the principle, we "just" need to do it :-). And figure
>>> out some details.
>>
>> Will that be Subversion 18.04 Anticlimactic Albatross?
>
> Please, please, DON'T do names like that!!!

Hehe, no :-).

In fact, we haven't really talked about version numbers / names in
this thread, and I'd like to keep it that way. I think this is
orthogonal to "should we go for time-based releases?". I suggest if
someone wants to discuss our versioning scheme, he/she should start a
new thread. Otherwise, I think we should just stick with our current
versioning scheme for now [1].

[1] http://subversion.apache.org/docs/community-guide/releasing.html#release-numbering

--
Johan