BUILD FAILURE: Jackrabbit Oak - Build # 1967 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #1967) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/1967/ to view the results. Changes: [reschke] OAK-8074: RDB*Store: update mysql-connector-java dependency to 8.0.15 Test results: All tests passed<>
Intent to backport OAK-8069
Hi, I would like to backport OAK-8069 to Oak 1.10 and 1.8. This introduced some logging to catch cases where many direct child nodes are added to a node transiently. Risk is relatively low as there are no functional changes, just logging. Michael
Reminder about fixVersion
Hi there. When resolving a bug in Jira, please make sure fixVersion is set properly: 1) to the next major release (right now 1.12), and 2) to the concrete releases it will be fixed in. Best regards, Julian
intent to backport OAK-8072
Hi all, I'd like to backport OAK-8072 [1] to 1.10 and 1.8 branches, if there's no objection. Regards, Tommaso [1] : https://issues.apache.org/jira/browse/OAK-8072
Re: [DISCUSS] branching and release strategies
Reading up through this, all sound good to me! Cheers, Woonsan On Thu, Feb 21, 2019 at 6:45 AM Davide Giannella wrote: > > So much for having said... ;) > > Please let's focus on the process here and ignore the version number. > > In-line as usual > > On 20/02/2019 14:54, Marcel Reutegger wrote: > > Hi, > > > > On 20.02.19, 13:21, "Robert Munteanu" wrote: > >> On Wed, 2019-02-20 at 10:45 +, Davide Giannella wrote: > >>> - Any previous oak release will be automatically deprecated. What has > >>> been already branched and released still stays there. This applies > >>> only > >>> to future releases. > >> So say we release 1.12 from trunk and then 1.12.1 from trunk. Does that > >> mean that 1.12 becomes instantly deprecated? > > I wouldn't call it deprecated, but 1.12.1 will be the new recommended > > version. This specific situation is very similar to how we do maintenance > > releases. The most recent release from a maintenance branch is the one > > we recommend. > > True. By not having a branch we cannot deliver something limited to a > bug fix. So 1.12.1 will be the next good one with all the bells and > whistles. > > It will therefore happen that if we have 1.12.2 and someone reports > something against 1.12.0 the first thing will be to see if it's > reproducible in trunk. We won't have any branch and the user will have > to use the latest and greatest. > > >> Do we even plan to make minor releases such as 1.12.1 or will 1.13 > >> immediately follow after 1.12? > > That's a good question. In my view we could make micro releases based > > on what has changed since the last minor release. If it's just bug fixes, > > release as 1.12.1 otherwise move to 1.14. > > > > Note the even minor version. To avoid confusion, we could still say only > > even minor versions are considered stable release. Even though we > > wouldn't create releases anymore with uneven minor version numbers. > > I wanted to keep the version number discussion separate because it > involves more questions than answers. > > However I agree with Marcel. Rule of thumb IMO should be: only micro > releases other that there are changes justifying the minor change. I > would stick to even minor numbers as well to ease the understanding > keeping the same concept of even/odd - stable/unstable. By not having > any more unstable we won't have any more odd releases. > > Tanking from https://semver.org/ I think this could help us deliver new > version numbers and is what I was taught in school "few" years ago :) > > Given a version number MAJOR.MINOR.PATCH, increment the: > > 1. MAJOR version when you make incompatible API changes, > 2. MINOR version when you add functionality in a backwards-compatible > manner, and > 3. PATCH version when you make backwards-compatible bug fixes. > > Given the above rules (if fine with everyone) we'll have a versioning > schema that makes us increasing `major` every time we need to branch. > Because for us branching will be always around backward incompatible > changes. > > Additionally we won't have `patch` numbers because, for the above > discussion, any release will probably always have a mix of features and > bug fixes. So we may end up in having 1.12, 1.14, 1.16, etc. > > Davide >
Re: [DISCUSS] branching and release strategies
So much for having said... ;) > Please let's focus on the process here and ignore the version number. In-line as usual On 20/02/2019 14:54, Marcel Reutegger wrote: > Hi, > > On 20.02.19, 13:21, "Robert Munteanu" wrote: >> On Wed, 2019-02-20 at 10:45 +, Davide Giannella wrote: >>> - Any previous oak release will be automatically deprecated. What has >>> been already branched and released still stays there. This applies >>> only >>> to future releases. >> So say we release 1.12 from trunk and then 1.12.1 from trunk. Does that >> mean that 1.12 becomes instantly deprecated? > I wouldn't call it deprecated, but 1.12.1 will be the new recommended > version. This specific situation is very similar to how we do maintenance > releases. The most recent release from a maintenance branch is the one > we recommend. True. By not having a branch we cannot deliver something limited to a bug fix. So 1.12.1 will be the next good one with all the bells and whistles. It will therefore happen that if we have 1.12.2 and someone reports something against 1.12.0 the first thing will be to see if it's reproducible in trunk. We won't have any branch and the user will have to use the latest and greatest. >> Do we even plan to make minor releases such as 1.12.1 or will 1.13 >> immediately follow after 1.12? > That's a good question. In my view we could make micro releases based > on what has changed since the last minor release. If it's just bug fixes, > release as 1.12.1 otherwise move to 1.14. > > Note the even minor version. To avoid confusion, we could still say only > even minor versions are considered stable release. Even though we > wouldn't create releases anymore with uneven minor version numbers. I wanted to keep the version number discussion separate because it involves more questions than answers. However I agree with Marcel. Rule of thumb IMO should be: only micro releases other that there are changes justifying the minor change. I would stick to even minor numbers as well to ease the understanding keeping the same concept of even/odd - stable/unstable. By not having any more unstable we won't have any more odd releases. Tanking from https://semver.org/ I think this could help us deliver new version numbers and is what I was taught in school "few" years ago :) Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Given the above rules (if fine with everyone) we'll have a versioning schema that makes us increasing `major` every time we need to branch. Because for us branching will be always around backward incompatible changes. Additionally we won't have `patch` numbers because, for the above discussion, any release will probably always have a mix of features and bug fixes. So we may end up in having 1.12, 1.14, 1.16, etc. Davide
