You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2011/12/06 16:24:10 UTC

Jackrabbit 2.4 release plan

Hi,

As mentioned earlier, we seem to be getting closer to a point where we
could branch Jackrabbit 2.4 and start targeting towards a stable 2.4.0
release. This is my suggestion on how and when we should do this.

I will be cutting a 2.3.5 release candidate from trunk shortly and
target for a 2.3.6 release in two weeks on Dec 20th. Both versions
exists in Jira.

At that point, on Dec 20th, we'll create the 2.4 branch and update
trunk version to 2.6-SNAPSHOT. Only bugfixes should be merged to the
2.4 branch unless there's a very good reason for why a broader change
should still be included. Thus, if you're working on some improvement,
new feature or API change that should be included in 2.4, please
target to have at least the key parts in place already for the 2.3.6
release.

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. If
you know of any bugs that should be addressed before the release,
please mark them in Jira using the 2.4 version.

BR,

Jukka Zitting

Re: Jackrabbit 2.4 release plan

Posted by 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

Posted by 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

Posted by 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

Posted by 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

Re: Jackrabbit 2.4 release plan

Posted by 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

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Tue, Dec 6, 2011 at 4:24 PM, Jukka Zitting <ju...@gmail.com> wrote:
> At that point, on Dec 20th, we'll create the 2.4 branch and update
> trunk version to 2.6-SNAPSHOT.

Done. Like the 2.3.x releases we've been making from 2.4-SNAPSHOT, the
plan is to start making unstable 2.5.x releases from the 2.6-SNAPSHOT
trunk again when there's enough demand to get latest developments out.

> Only bugfixes should be merged to the 2.4 branch unless there's
> a very good reason for why a broader change should still be included.

It looks like we still have some broader changes going on in trunk
that ideally should go into 2.4, so I'd evaluate this rule on a
case-by-case basis for now until we make the official 2.4.0 release.
If there's a lot of such changes, we may still opt to do an unstable
2.3.7 release from the 2.4 branch before switching to stable 2.4.x
releases.

When working on changes that should go into the 2.4 branch, please use
the 2.4 version in Jira. For other changes use the 2.5 version.

All changes should be committed first to the trunk. If you like, you
can also merge them to the 2.4 branch using "svn merge -c NNN
^/jackrabbit/trunk" from a checkout of the branch. Otherwise, if the
issue is marked for 2.4 in Jira, I'll make sure that any relevant
changes are merged before cutting the release.

BR,

Jukka Zitting