Re: Jackrabbit 2.4 release plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Dec 6, 2011 at 4:24 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Two weeks later, on Tuesday Jan 3rd, and assuming no big problems have
> been detected, we'll then cut the stable 2.4.0 release candidate.

The 2.3.6 release announcement got delayed since I didn't have ssh
access required for staging the release over the holidays. The release
is finally now up and I just sent out the release announcement, but
it's probably best to give some time for people to try it out before
we cut 2.4.0.

And there hasn't been much work in trunk or the 2.4 branch since the
2.3.6, so also from that perspective we should let things rest a bit
longer before cutting the first stable 2.4 release.

Thus I suggest that we postpone the 2.4.0 cut date two weeks ahead to
Tuesday, Jan 17th. Any help before that in testing the 2.3.6 release
and pointing out any pending fixes in Jira will be much appreciated.

BR,

Jukka Zitting

Re: Jackrabbit 2.4 release plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Jan 31, 2012 at 3:26 PM, Torgeir Veimo <to...@netenviron.com> wrote:
> Any hope for support for lucene version > 3.3?

I think it's too late for a potentially risky change like that. It
would have been great to integrate such a change a few weeks or months
ago for 2.3.x if there had been a patch that passed all integration
tests. Now it's best to postpone the Lucene upgrade to Jackrabbit
2.5.x.

BR,

Jukka Zitting

Re: Jackrabbit 2.4 release plan

[Torgeir Veimo <to...@netenviron.com>]

On 1 February 2012 00:07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Mon, Jan 16, 2012 at 6:46 PM, Jukka Zitting <ju...@gmail.com> wrote:
>> I think we should postpone cutting the 2.4.0 release two weeks ahead
>> to the end of January.
>
> OK, I think it's now time to start making the release. I already
> started drafting the release notes, and will still go through the
> issue tracker for any pending tasks that we may have missed.
>
> I won't cut the release candidate before tomorrow at the earliest, so
> if you still have some improvements that really should be in 2.4 but
> aren't committed yet, please let me know and I'll see what we can do
> to get them included. Once the 2.4.0 release is out, we'll switch the
> 2.4 branch to maintenance mode and target all new features to the
> unstable 2.5.x release series.

Any hope for support for lucene version > 3.3?


-- 
-Tor

Re: Jackrabbit 2.4 release plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Mon, Jan 16, 2012 at 6:46 PM, Jukka Zitting <ju...@gmail.com> wrote:
> I think we should postpone cutting the 2.4.0 release two weeks ahead
> to the end of January.

OK, I think it's now time to start making the release. I already
started drafting the release notes, and will still go through the
issue tracker for any pending tasks that we may have missed.

I won't cut the release candidate before tomorrow at the earliest, so
if you still have some improvements that really should be in 2.4 but
aren't committed yet, please let me know and I'll see what we can do
to get them included. Once the 2.4.0 release is out, we'll switch the
2.4 branch to maintenance mode and target all new features to the
unstable 2.5.x release series.

BR,

Jukka Zitting

Re: Jackrabbit 2.4 release plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Mon, Jan 2, 2012 at 5:17 PM, Jukka Zitting <ju...@gmail.com> wrote:
> And there hasn't been much work in trunk or the 2.4 branch since the
> 2.3.6, so also from that perspective we should let things rest a bit
> longer before cutting the first stable 2.4 release.
>
> Thus I suggest that we postpone the 2.4.0 cut date two weeks ahead to
> Tuesday, Jan 17th.

We actually did get some active work done on areas like locking
(including a new configuration option) and I'd like to complete
exposing the query stats by Alex through JMX interfaces before 2.4, so
I think we should postpone cutting the 2.4.0 release two weeks ahead
to the end of January. Instead I'll tomorrow cut a 2.3.7 release
candidate from the latest 2.4 branch after merging any relevant
changes from trunk.

BR,

Jukka Zitting