hi ok i see... as long as my improvmeents stay (or get properly reapplied) on jackrabbit trunk and get released with the next (instable) 2.x.y, i am all fine and don't mind about the details on how we get there... i just don't want to run after a broken oak.
what we also might want to consider on the long run: i stopped implemented new API extensions in jackrabbit 2.x in order to minimise the effort to implement, test and maintain it. why can't we envision having separate releases for jackrabbit-api and possibly jackrabbit-jcr-commons and keep jackrabbit-core on untouched old versions? kind regards angela On 06/08/15 11:05, "Michael Dürig" <[email protected]> wrote: > > >On 6.8.15 10:51 , Angela Schreiber 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. > >This is only about reverting so we can create the branch without the API >changes and immediately re-apply said commit again afterwards. > >Michael > >> >> 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 >>> >>> >>
