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
