Re: [VOTE] Release Apache Jackrabbit 2.10.2
[INFO] [INFO] ALL CHECKS OK [INFO] [X] +1 Release this package as Apache Jackrabbit 2.10.2 [ ] -1 Do not release this package because... Cédric
Re: [VOTE] Release Apache Jackrabbit 2.10.2
On 23/03/16 17:48, "Davide Giannella" wrote: >Please vote on releasing this package as Apache Jackrabbit 2.10.2. >The vote is open for the next 72 hours and passes if a majority of at >least three +1 Jackrabbit PMC votes are cast. All checks OK. +1 Release this package as Apache Jackrabbit 2.10.2 Regards Marcel
Re: [VOTE] Release Apache Jackrabbit 2.10.2
Hi, Since, the voting period overlapped with the long weekend we should we extend the vote another 72 hours. Thanks Amit On Wed, Mar 23, 2016 at 10:18 PM, Davide Giannellawrote: > A candidate for the Jackrabbit 2.10.2 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/2.10.2/ > > The release candidate is a zip archive of the sources in: > > https://svn.apache.org/repos/asf/jackrabbit/tags/2.10.2/ > > The SHA1 checksum of the archive is > 89bca1da469bea4e37f7503fff453a275d2e952a. > > A staged Maven repository is available for review at: > > https://repository.apache.org/ > > The command for running automated checks against this release candidate is: > > $ sh check-release.sh 2.10.2 89bca1da469bea4e37f7503fff453a275d2e952a > > Please vote on releasing this package as Apache Jackrabbit 2.10.2. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. > > [ ] +1 Release this package as Apache Jackrabbit 2.10.2 > [ ] -1 Do not release this package because... > > Davide >
Re: [VOTE] Release Apache Jackrabbit 2.10.2
On Wed, Mar 23, 2016 at 10:18 PM, Davide Giannellawrote: > > Please vote on releasing this package as Apache Jackrabbit 2.10.2. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. +1 Release this package as Apache Jackrabbit 2.10.2 Thanks Amit
Re: [VOTE] Release Apache Jackrabbit 2.10.2
[X] +1 Release this package as Apache Jackrabbit 2.10.2 Davide
Re: [VOTE] Release Apache Jackrabbit 2.10.2
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 dav...@apache.org 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
Re: [VOTE] Release Apache Jackrabbit 2.10.2
Hi Chetan, On Thu, Aug 6, 2015 at 11:00 AM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: On Thu, Aug 6, 2015 at 2:21 PM, Angela Schreiber anch...@adobe.com wrote: i am fine... quite frankly i am surprised to see that there is no 2.10 branch. I think this was discussed earlier [1]. Looks like we would have to revisit that decision and continue with stable/unstable releases Precisely! The assumption at the time was that trunk would stay in a maintenance mode. That assumption is not valid any longer imo and we should create the 2.10 release branch. I would prefer to have a stable/non breaking next 2.10 release following the 2.10.1 release. How exactly we get there, branch first then revert, revert first-branch-recommit, or branch from revission/tag, doesn't matter that much. Regards, Bart Chetan Mehrotra [1] http://markmail.org/thread/p7k6lzbebgrgoz63
Re: [VOTE] Release Apache Jackrabbit 2.10.2
On Thu, Aug 6, 2015 at 10:51 AM, Angela Schreiber anch...@adobe.com 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 dav...@apache.org 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
Re: [VOTE] Release Apache Jackrabbit 2.10.2
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 mdue...@apache.org 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 dav...@apache.org 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
Re: [VOTE] Release Apache Jackrabbit 2.10.2
On Thu, Aug 6, 2015 at 2:21 PM, Angela Schreiber anch...@adobe.com wrote: i am fine... quite frankly i am surprised to see that there is no 2.10 branch. I think this was discussed earlier [1]. Looks like we would have to revisit that decision and continue with stable/unstable releases Chetan Mehrotra [1] http://markmail.org/thread/p7k6lzbebgrgoz63
Re: [VOTE] Release Apache Jackrabbit 2.10.2
[X] -1 Do not release this package because... it says svn: E17: URL 'https://svn.apache.org/repos/asf/jackrabbit/tags/2.10.2' doesn't exist and indeed it doesn't. By looking at SVN I can find that since 2.10.1 the tag created are `jackrabbit-VERSION` rather than `VERSION`. I searched through the archives buy couldn't find any references to changes or so. Does anybody have any info with regards to it? I'm ok with changing the check-release.sh if something has changed. Cheers Davide
Re: [VOTE] Release Apache Jackrabbit 2.10.2
Hi Davide, 2.10.1 was mistakenly tagged as jackrabbit-2.10.1 and maybe that carried over. Not sure whether its an option here but can't we just rename the tag in svn? Thanks Amit On Wed, Aug 5, 2015 at 12:25 PM, Davide Giannella dav...@apache.org wrote: [X] -1 Do not release this package because... it says svn: E17: URL 'https://svn.apache.org/repos/asf/jackrabbit/tags/2.10.2' doesn't exist and indeed it doesn't. By looking at SVN I can find that since 2.10.1 the tag created are `jackrabbit-VERSION` rather than `VERSION`. I searched through the archives buy couldn't find any references to changes or so. Does anybody have any info with regards to it? I'm ok with changing the check-release.sh if something has changed. Cheers Davide
Re: [VOTE] Release Apache Jackrabbit 2.10.2
On 05/08/2015 10:01, Amit Jain wrote: Hi Davide, 2.10.1 was mistakenly tagged as jackrabbit-2.10.1 and maybe that carried over. Not sure whether its an option here but can't we just rename the tag in svn? Theoretically possible by something like svn mv \ https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.10.2/ \ https://svn.apache.org/repos/asf/jackrabbit/tags/2.10.2/ If no one object I will be doing it tomorrow after lunch CEST. Davide
Re: [VOTE] Release Apache Jackrabbit 2.10.2
I'm also -1 on this release but for a different reason. It seems that there are (again) API changes in a maintenance tag [1]. I've already indicated that I don't agree with this procedure. That API changes need to be made on a 2.12 branch only. 1. Changesets 1694048 and 1693235 2. http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/40628 On Wed, Aug 5, 2015 at 2:27 PM, Davide Giannella dav...@apache.org wrote: On 05/08/2015 10:01, Amit Jain wrote: Hi Davide, 2.10.1 was mistakenly tagged as jackrabbit-2.10.1 and maybe that carried over. Not sure whether its an option here but can't we just rename the tag in svn? Theoretically possible by something like svn mv \ https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.10.2/ \ https://svn.apache.org/repos/asf/jackrabbit/tags/2.10.2/ If no one object I will be doing it tomorrow after lunch CEST. Davide
Re: [VOTE] Release Apache Jackrabbit 2.10.2
On 05/08/2015 14:27, Davide Giannella wrote: On 05/08/2015 10:01, Amit Jain wrote: Hi Davide, 2.10.1 was mistakenly tagged as jackrabbit-2.10.1 and maybe that carried over. Not sure whether its an option here but can't we just rename the tag in svn? Theoretically possible by something like svn mv \ https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.10.2/ \ https://svn.apache.org/repos/asf/jackrabbit/tags/2.10.2/ If no one object I will be doing it tomorrow after lunch CEST. I gave a look at parent pom and reactor pom and didn't find any references of jackrabbit-VERSION tag vs VERSION tag. Which could easily be that it's carried over the 2.10.1 but that we simply have to remember to re-set it properly on 2.10.3. Davide
Re: [VOTE] Release Apache Jackrabbit 2.10.2
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? Regards, Bart On Wed, Aug 5, 2015 at 2:45 PM, Unico Hommes un...@apache.org wrote: I'm also -1 on this release but for a different reason. It seems that there are (again) API changes in a maintenance tag [1]. I've already indicated that I don't agree with this procedure. That API changes need to be made on a 2.12 branch only. 1. Changesets 1694048 and 1693235 2. http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/40628 On Wed, Aug 5, 2015 at 2:27 PM, Davide Giannella dav...@apache.org wrote: On 05/08/2015 10:01, Amit Jain wrote: Hi Davide, 2.10.1 was mistakenly tagged as jackrabbit-2.10.1 and maybe that carried over. Not sure whether its an option here but can't we just rename the tag in svn? Theoretically possible by something like svn mv \ https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.10.2/ \ https://svn.apache.org/repos/asf/jackrabbit/tags/2.10.2/ If no one object I will be doing it tomorrow after lunch CEST. Davide -- Hippo B.V. - Oosteinde 11, 1017 WT Amsterdam Hippo USA, Inc. - 745 Atlantic Ave, Third Floor, Boston, MA 02111 US +1 877 414 4776 (toll free) Europe +31(0)20 522 4466 www.onehippo.com
Re: [VOTE] Release Apache Jackrabbit 2.10.2
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