You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Davide Giannella <da...@apache.org> on 2015/08/04 21:35:35 UTC
[VOTE] Release Apache Jackrabbit 2.10.2
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
a4fc082b0f0ba798cf5cd2d24acbfbde4d279206.
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 a4fc082b0f0ba798cf5cd2d24acbfbde4d279206
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...
Re: [VOTE] Release Apache Jackrabbit 2.10.2
Posted by Angela Schreiber <an...@adobe.com>.
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" <md...@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" <da...@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
Posted by Michael Dürig <md...@apache.org>.
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" <da...@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
Posted by Unico Hommes <un...@apache.org>.
On Thu, Aug 6, 2015 at 10:51 AM, Angela Schreiber <an...@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" <da...@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
Posted by Bart van der Schans <b....@onehippo.com>.
Hi Chetan,
On Thu, Aug 6, 2015 at 11:00 AM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> On Thu, Aug 6, 2015 at 2:21 PM, Angela Schreiber <an...@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
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Thu, Aug 6, 2015 at 2:21 PM, Angela Schreiber <an...@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
Posted by Angela Schreiber <an...@adobe.com>.
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" <da...@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
Posted by Davide Giannella <da...@apache.org>.
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
Posted by Bart van der Schans <b....@onehippo.com>.
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 <da...@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
Posted by Unico Hommes <un...@apache.org>.
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 <da...@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
Posted by Davide Giannella <da...@apache.org>.
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
Posted by Davide Giannella <da...@apache.org>.
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
Posted by Amit Jain <am...@ieee.org>.
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 <da...@apache.org> wrote:
> [X] -1 Do not release this package because...
>
> it says
>
> svn: E170000: 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
Posted by Davide Giannella <da...@apache.org>.
[X] -1 Do not release this package because...
it says
svn: E170000: 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