jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Fwd: [DISCUSS] branching and release strategies
Date Wed, 20 Feb 2019 10:58:28 GMT

FYI: we are discussing changing the release strategy of Jackrabbit Oak 
on the oak-dev mailing list.

If you're interested and not subscribed to that list, it might be a good 
idea to do that now. Please do not reply to this forwarded mail or 
cross-post... :-)

Once we have consensus for Oak we will then discuss over here whether 
that'll require changes in Jackrabbit's release strategy.

Best regards, Julian

-------- Forwarded Message --------
Subject: [DISCUSS] branching and release strategies
Date: Wed, 20 Feb 2019 10:45:56 +0000
From: Davide Giannella <davide@apache.org>
Reply-To: oak-dev@jackrabbit.apache.org
To: oak-dev <oak-dev@jackrabbit.apache.org>

Good morning team,

there were some discussions face to face between some of the Oak team
members about the many branches we currently have to support and how we
could better support the changing world around releases of "tools" we
use. Most notably is the JVM support and release model from Oracle.

We came out with the following proposal for future development; what
currently is: `1.12-SNAPSHOT`.

Please let's focus on the process here and ignore the version number.

*Key Facts*

- Trunk will be considered stable

- We'll need to pay extra attention to commit in trunk. Moving therefore
a more feature-branch oriented approach when needed rather than simply
committing to trunk.

- There will be releases only from trunk

- Any previous oak release will be automatically deprecated. What has
been already branched and released still stays there. This applies only
to future releases.


Now it may come the case when we NEED to branch for a reason or another.
This is most probably going to happen for technical reasons like, but
not limited to, the following

- incompatible changes in the API

- incompatible changes in the JVM which we may have or want to use

- updates to dependencies that break backwards compatibility

In such cases we'll discuss the best course of action between branching
and changing the breaking change. If branching we'll go back in time
(svn speaking) branching off at the last good revision. The branch will
then follow the usual support model.


For trunk probably the best frequency will be around the "once a month"
mark. Maybe even longer. Definitely not shorter as there may not be time
to allow discussions and tests to happen before cutting the release.

*Jackrabbit 2*

So what is going to happen to jackrabbit 2? Release wise it won't change
for jackrabbit. It will be treated as a separate product and Oak will
use a stable version in trunk. If/When the needs will arise and there
will be an incompatible change in JR, we'll coordinate on a per-case
basis. Most probably the process will be:

- release JR unstable

- integrate JR unstable in oak and test

- branch or backport JR change and release stable

- update Oak to next stable JR


View raw message