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. 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. 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 > >
