On Thu, Aug 6, 2015 at 10:51 AM, Angela Schreiber <[email protected]> wrote: > hi > > -1 for reverting the changes. i only applied them to the > trunk (and not to a released branch, which i never intended > to do) and i don't see any reason why extending the API should > not be possible there. > > the jackrabbit trunk always used to point to the 'unstable' > work in progress and was open for extensions... if that's no > longer the case then we have a fundamental misunderstanding > on how we work with jackrabbit and how we can extend it. > this is crucial for us at adobe... i didn't add the extensions > just for the sake of it but rather because we have customers > waiting for it.
That's exactly the problem now. That the minor version on the trunk is the current stable version, 2.10.x. Yes, a branch should have been created before. And Bart's proposal is to do that now. Your changes will stay on the trunk, but the trunk will have a different version, 2.11.x, which according to the odd/even scheme is not stable wrt to the API. Bart's mention of reverting is only very temporary in order to create a branch, but it's also possible to first create a branch and revert your changes on the branch. Effectively it is the same. > > which number that has associated with i don't care too much. > if we can reach consensus by creating a 2.10 branch from the > revision where we created the last 2.10.1 release, i am fine... > quite frankly i am surprised to see that there is no 2.10 > branch. I think we agree. -- Unico > > kind regards > angela > > > > On 05/08/15 21:05, "Davide Giannella" <[email protected]> wrote: > >>On 05/08/2015 17:58, Bart van der Schans wrote: >>> Hi guys, >>> >>> I really have to agree with Unico here. We should not make API changes >>> in the stable "branch". These changes create (a lot of) unexpected >>> work for everybody depending on Jackrabbit with their own projects. If >>> we do need API changes we have to branch off 2.10 first in a stable >>> maintenance branch. We can set the trunk to 2.11 with the odd/even >>> scheme, so we still can create tags as we need them while indicating >>> that these tags are not considered stable and indeed the API might >>> still change. >>> >>> So my proposal is to: >>> - revert the API breaking changes >>> - create the 2.10 branch >>> - set the version in trunk to 2.11 >>> - create a new 2.10.3 tag of the branch in which we can fix the tag >>> naming as well >>> - re-apply the reverted changes to trunk >>> - create a 2.11.0 tag if needed >>> >>> Of course Unico and I can help with doing this. >>> >>> Wdyt? >> >>On my side I agree on the API aspect of the situation but can't >>contribute too much as I'm not that familiar with JR codebase. >> >>Angela the changes were yours. What do you think of the above plan? >> >>On the release side I would say we wait for the 72hrs expiration and >>most probably it will fail anyhow. It will be on Monday morning. So I >>won't touch anything. >> >>Davide >> >> >
