Re: Jackrabbit 1.6 release plan
Hi, Here's hoping we'd finally be ready for the release... We've resolved both JCR-422 and JCR-1972 and all the other issues people have been asking for the 1.6 release. I've just created the 1.6 branch and started preparing the release notes. Unless anything major comes up, I'm planning to cut the 1.6.0 release candidate on Friday. BR, Jukka Zitting
Re: Jackrabbit 1.6 release plan
On Wed, Jul 8, 2009 at 11:37, Jukka Zittingjukka.zitt...@gmail.com wrote: Let me know if there's anything missing from the 1.x branch that you'd like included in the 1.6.0 release. FYI, I've merged the changes for JCR- into the 1.x branch. regards marcel
Re: Jackrabbit 1.6 release plan
Hi, On Mon, Jun 29, 2009 at 12:36 PM, Martijn Hendriksmarti...@gx.nl wrote: Is it possible to include JCR-2129, JCR-2138 and JCR-2168 in jackrabbit 1.6.0? Yes, I merged them all to the 1.x branch yesterday. I'm now planning to move forward with the 1.6.0 release, even if the backup/migration feature isn't fully complete yet. We can add the missing pieces later in the 1.6.x cycle. Let me know if there's anything missing from the 1.x branch that you'd like included in the 1.6.0 release. BR, Jukka Zitting
RE: Jackrabbit 1.6 release plan
Great, thanks! Martijn Van: Jukka Zitting [jukka.zitt...@gmail.com] On Mon, Jun 29, 2009 at 12:36 PM, Martijn Hendriksmarti...@gx.nl wrote: Is it possible to include JCR-2129, JCR-2138 and JCR-2168 in jackrabbit 1.6.0? Yes, I merged them all to the 1.x branch yesterday.
Re: Using the patch-available workflow in Jira (Was: Jackrabbit 1.6 release plan)
Hi, On Tue, Jul 7, 2009 at 3:22 PM, Jukka Zittingjukka.zitt...@gmail.com wrote: I've now changed the JCR project to use the no-reopen-closed, patch-avail workflow. I browsed through all our open issues for ones with patches waiting for action and moved them to the Patch Available state (sorry for the notification noise). See https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10591status=10002 for the list of issues waiting for committer action. BR, Jukka Zitting
Re: Jackrabbit 1.6 release plan
Hi Jukka, I created an issue about a deadlock a few weeks ago. I was unable to create a Jackrabbit test case but my business test case always reproduces the deadlock. But, i posted the java stack trace [1] in order to help finding the race condition. I know this issue is not fixed yet, but i thought there is better chances to see it merged into 1.6 branch if it implies important changes than into 1.5 branch. I try again to create a test case but i do not have enough understanding of Jackrabbit lock management, especially in SharedItemStateManager component. [1] https://issues.apache.org/jira/browse/JCR-2171 Jukka Zitting a écrit : Yes, I merged them all to the 1.x branch yesterday. I'm now planning to move forward with the 1.6.0 release, even if the backup/migration feature isn't fully complete yet. We can add the missing pieces later in the 1.6.x cycle. Let me know if there's anything missing from the 1.x branch that you'd like included in the 1.6.0 release. BR, Jukka Zitting -- Sébastien Launay
Re: Jackrabbit 1.6 release plan
Hi, On Wed, Jul 8, 2009 at 2:39 PM, Sébastien Launaysebastien.lau...@anyware-tech.com wrote: I created an issue about a deadlock a few weeks ago. I was unable to create a Jackrabbit test case but my business test case always reproduces the deadlock. But, i posted the java stack trace [1] in order to help finding the race condition. Thanks for the pointer. I gave the issue a quick look and I think I know what's happening. Can you try out the patch I attached in JCR-2171? It should apply cleanly also to the 1.x or 1.5 branches. BR, Jukka Zitting
Re: Using the patch-available workflow in Jira (Was: Jackrabbit 1.6 release plan)
Hi, On Tue, May 26, 2009 at 3:11 PM, Jukka Zittingjukka.zitt...@gmail.com wrote: Any objections to changing the workflow? If not, then I'll change the Jira settings accordingly. I've now changed the JCR project to use the no-reopen-closed, patch-avail workflow. Contributors: When you've attached a patch that you want reviewed, please use the Submit Patch option in Jira to move the issue to the Patch Available state. This way it'll be easier for the committers to find and review. BR, Jukka Zitting
RE: Jackrabbit 1.6 release plan
Hi, Is it possible to include JCR-2129, JCR-2138 and JCR-2168 in jackrabbit 1.6.0? Best regards, Martijn Hendriks -Original Message- From: Jukka Zitting [mailto:jukka.zitt...@gmail.com] Sent: Thursday, June 18, 2009 4:16 PM To: Jackrabbit Developers Subject: Re: Jackrabbit 1.6 release plan Hi, To answer Thomas' comment from JCR-2128, I'm still planning to do the 1.6 release. The current blocker is finishing up the backup/migration tool I added some weeks ago (JCR-422). Mostly some extra work is needed in how to best handle search indexes and the data store. The reason why I want this tool to be included in the 1.6 release is to simplify any migration tasks that may be necessary when upgrading to Jackrabbit 2.0. BR, Jukka Zitting
Re: Jackrabbit 1.6 release plan
Hi, To answer Thomas' comment from JCR-2128, I'm still planning to do the 1.6 release. The current blocker is finishing up the backup/migration tool I added some weeks ago (JCR-422). Mostly some extra work is needed in how to best handle search indexes and the data store. The reason why I want this tool to be included in the 1.6 release is to simplify any migration tasks that may be necessary when upgrading to Jackrabbit 2.0. BR, Jukka Zitting
Using the patch-available workflow in Jira (Was: Jackrabbit 1.6 release plan)
Hi, 2009/5/25 Cédric Damioli cedric.dami...@anyware-tech.com: We provided a patch several months ago, but AFAIK nobody reviewed it. We've now had already a few cases like this where a perfectly good patch gets overlooked for months at a time. That's not a a good sign, so I'd like to find some way to fix this. We currently have almost 300 open issues in Jira, so unless you already know which issue has a patch available it's hard to go looking for patches to apply. To avoid this problem I'd like to adopt the no-reopen-closed, patch-avail workflow in our main Jira project. The JCR Commons component projects in Jira have already been set up with this workflow. This workflow is just like what we have now with two differences: 1) A closed issue can't be reopened. This works well for our Jira practices, as we normally resolve an issue when it's fixed and close it when the fix is released. After that the issue should no longer be reopened to avoid 2) There's a new optional issue status called patch available. A contributor can move an issue from open to patch available, and a committer can then move it either back to open if the patch is rejected or resolved if the patch is accepted. The good thing about this is that with this extra status we can easily list just those issues that have patches waiting for review. Any objections to changing the workflow? If not, then I'll change the Jira settings accordingly. BR, Jukka Zitting
AW: Using the patch-available workflow in Jira (Was: Jackrabbit 1.6 release plan)
+1 greets claus This workflow is just like what we have now with two differences: 1) A closed issue can't be reopened. This works well for our Jira practices, as we normally resolve an issue when it's fixed and close it when the fix is released. After that the issue should no longer be reopened to avoid 2) There's a new optional issue status called patch available. A contributor can move an issue from open to patch available, and a committer can then move it either back to open if the patch is rejected or resolved if the patch is accepted. The good thing about this is that with this extra status we can easily list just those issues that have patches waiting for review. Any objections to changing the workflow? If not, then I'll change the Jira settings accordingly.
Re: Using the patch-available workflow in Jira (Was: Jackrabbit 1.6 release plan)
+1 Ian On 26 May 2009, at 14:11, Jukka Zitting wrote: Hi, 2009/5/25 Cédric Damioli cedric.dami...@anyware-tech.com: We provided a patch several months ago, but AFAIK nobody reviewed it. We've now had already a few cases like this where a perfectly good patch gets overlooked for months at a time. That's not a a good sign, so I'd like to find some way to fix this. We currently have almost 300 open issues in Jira, so unless you already know which issue has a patch available it's hard to go looking for patches to apply. To avoid this problem I'd like to adopt the no-reopen-closed, patch-avail workflow in our main Jira project. The JCR Commons component projects in Jira have already been set up with this workflow. This workflow is just like what we have now with two differences: 1) A closed issue can't be reopened. This works well for our Jira practices, as we normally resolve an issue when it's fixed and close it when the fix is released. After that the issue should no longer be reopened to avoid 2) There's a new optional issue status called patch available. A contributor can move an issue from open to patch available, and a committer can then move it either back to open if the patch is rejected or resolved if the patch is accepted. The good thing about this is that with this extra status we can easily list just those issues that have patches waiting for review. Any objections to changing the workflow? If not, then I'll change the Jira settings accordingly. BR, Jukka Zitting
Re: Jackrabbit 1.6 release plan
Hi, On Tue, Apr 21, 2009 at 5:10 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: As noted in various recent threads, we're getting closer to branching and releasing Jackrabbit 1.6. There are no major blockers to 1.6 so we should be able to move fairly quickly with the release. The 1.x branch is in a pretty good state so I'm planning to cut the 1.6.0 release sometime next week. BR, Jukka Zitting
Re: Jackrabbit 1.6 release plan
Hi Jukka, Could JCR-134 be part of the 1.6 release ? We provided a patch several months ago, but AFAIK nobody reviewed it. This patch is really helpful, as it allows repositories not to grow unnecessarily over time [1] There's also a few threads on mailing-lists asking for this feature [2] The patch in the JIRA is quite old (was made for 1.4.x), so please tell us if we must post another one. Regards, Cédric [1] http://issues.apache.org/jira/browse/JCR-134 [2] http://markmail.org/thread/l5rd5em3xxbg44jx Jukka Zitting a écrit : Hi, On Tue, Apr 21, 2009 at 5:10 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: As noted in various recent threads, we're getting closer to branching and releasing Jackrabbit 1.6. There are no major blockers to 1.6 so we should be able to move fairly quickly with the release. The 1.x branch is in a pretty good state so I'm planning to cut the 1.6.0 release sometime next week. BR, Jukka Zitting -- Cédric Damioli ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 73 47 Mob : +33 (0)6 87 03 61 63 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com http://www.ametys.fr / http://www.ametys.org Ce message et toutes les pièces jointes (le Message) sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Anyware Technologies et sa maison mère Wavecom déclinent toute responsabilité au titre de ce Message s'il a été altéré, déformé, falsifié ou édité, diffusé sans autorisation.
Re: Jackrabbit 1.6 release plan
Hi, 2009/5/25 Cédric Damioli cedric.dami...@anyware-tech.com: Could JCR-134 be part of the 1.6 release ? We provided a patch several months ago, but AFAIK nobody reviewed it. Sorry about that, I'll give it a look now. Thanks for the heads up. BR, Jukka Zitting
Re: Jackrabbit 1.6 release plan
Hi, On Tue, Apr 21, 2009 at 5:10 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Unless anything major comes up, I will create a Jackrabbit 1.x branch at the end of next week on Friday, April 30th. That would of course be Thursday, April 30th. I'll never get used to calendars that start the week on Sunday! The JCR Commons migration is now done, so from my perspective everything is ready for creating the 1.x branch and switching the trunk to JCR 2.0. Unless anyone wishes otherwise, I will create the branch around noon tomorrow, on _Thursday_. BR, Jukka Zitting
Re: Jackrabbit 1.6 release plan
Hi,
I like to fix https://issues.apache.org/jira/browse/JCR-2063
(FileDataStore: garbage collection can delete files that are still needed)
Unfortunately, I can't get the data store unit tests to work; the
workspace is closed while the garbage collection is run
('idleTimeout'). I'm not sure if this is another bug...
Regards,
Thomas
On Tue, Apr 21, 2009 at 6:41 PM, Dan Diephouse
dan.diepho...@mulesource.com wrote:
I'm working on my cleaned up patch for JCR-1659 and a new one for JCR-977.
Hopefully by the end of the week
Dan
On Tue, Apr 21, 2009 at 11:10 AM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
Hi,
As noted in various recent threads, we're getting closer to branching
and releasing Jackrabbit 1.6. There are no major blockers to 1.6 so we
should be able to move fairly quickly with the release. We had some
earlier plans about including a content browser/editor or implementing
database connection pooling in 1.6, but since neither effort has moved
much forward I guess it's best to not wait for them.
I'm hoping to have the JCR Commons components moved outside the main
codebase before the Jackrabbit 1.6 release, so the more we can do
towards that before branching 1.6 the better. Also, the fewer
components we have in trunk, the easier the JCR 2.0 migration work
will be after 1.6 has been branched. I'll try to focus some effort on
that in the next few days.
Unless anything major comes up, I will create a Jackrabbit 1.x branch
at the end of next week on Friday, April 30th. This branch will be
used for any remaining JCR 1.0 feature work for Jackrabbit 1.6 (and a
potential Jackrabbit 1.7 release later on if there's demand for that).
Meanwhile the trunk will be upgraded to JCR 2.0. Once all feature
changes for Jackrabbit 1.6 are in (hopefully within a week or so after
the 1.x branch was created), I will branch 1.6 and cut the first
preview build of the release. At that point the 1.6 branch will go
into a bug fix -only mode.
If you have any major fixes or features you'd like to see in
Jackrabbit 1.6, now would be a good time to bring them up.
BR,
Jukka Zitting
--
Dan Diephouse
http://mulesource.com | http://netzooid.com/blog
Re: Jackrabbit 1.6 release plan
Hi, On Tue, Apr 21, 2009 at 6:41 PM, Dan Diephouse dan.diepho...@mulesource.com wrote: I'm working on my cleaned up patch for JCR-1659 and a new one for JCR-977. OK, good to know. BR, Jukka Zitting
Re: Jackrabbit 1.6 release plan
Hi,
On Wed, Apr 22, 2009 at 9:52 AM, Thomas Müller thomas.muel...@day.com wrote:
I like to fix https://issues.apache.org/jira/browse/JCR-2063
(FileDataStore: garbage collection can delete files that are still needed)
Unfortunately, I can't get the data store unit tests to work; the
workspace is closed while the garbage collection is run
('idleTimeout'). I'm not sure if this is another bug...
Could this be related to JCR-2048? The PersistenceManagerIteratorTest
started failing for a similar reason in the 1.5 branch when I merged
the JCR-2048 change there. I'm looking at the problem now.
BR,
Jukka Zitting
Re: Jackrabbit 1.6 release plan
Hi, Could this be related to JCR-2048? Yes. Please tell me if you want me to fix this problem. I propose to include in 1.6: https://issues.apache.org/jira/browse/JCR-2063 https://issues.apache.org/jira/browse/JCR-2080 Regards, Thomas
Jackrabbit 1.6 release plan
Hi, As noted in various recent threads, we're getting closer to branching and releasing Jackrabbit 1.6. There are no major blockers to 1.6 so we should be able to move fairly quickly with the release. We had some earlier plans about including a content browser/editor or implementing database connection pooling in 1.6, but since neither effort has moved much forward I guess it's best to not wait for them. I'm hoping to have the JCR Commons components moved outside the main codebase before the Jackrabbit 1.6 release, so the more we can do towards that before branching 1.6 the better. Also, the fewer components we have in trunk, the easier the JCR 2.0 migration work will be after 1.6 has been branched. I'll try to focus some effort on that in the next few days. Unless anything major comes up, I will create a Jackrabbit 1.x branch at the end of next week on Friday, April 30th. This branch will be used for any remaining JCR 1.0 feature work for Jackrabbit 1.6 (and a potential Jackrabbit 1.7 release later on if there's demand for that). Meanwhile the trunk will be upgraded to JCR 2.0. Once all feature changes for Jackrabbit 1.6 are in (hopefully within a week or so after the 1.x branch was created), I will branch 1.6 and cut the first preview build of the release. At that point the 1.6 branch will go into a bug fix -only mode. If you have any major fixes or features you'd like to see in Jackrabbit 1.6, now would be a good time to bring them up. BR, Jukka Zitting
