Mailing-List: contact dev-help@pdfbox.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@pdfbox.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4FA78CCE.9010306@ontochem.com>
References: 
 <CAL8PwkbMNuB+gzw204egHD_OHRRpCijXDvY4J3NwG23jdysiYg@mail.gmail.com>
 <4FA3DDC4.7080707@ontochem.com> <4FA68ECC.7020506@lehmi.de>
 <4FA78CCE.9010306@ontochem.com>
From: Michael McCandless <lucene@mikemccandless.com>
Date: Mon, 7 May 2012 06:14:02 -0400
Message-ID: 
 <CAL8PwkaWJ=FVkGpBpnjD-LeLpwBK08KTQAtvkTHxzyTx993mtg@mail.gmail.com>
Subject: Re: 1.7 release?
To: dev@pdfbox.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 7, 2012 at 4:50 AM, Timo Boehme <timo.boehme@ontochem.com> wrote:

> In my opinion there are already a number of improvements in current trunk
> compared to 1.6

+1

> and there is no reason to not release another 1.8 before
> PDFBOX-1000 is really ready. As I see it we should bump the version to 2.0
> if PDFBOX-1000 finally lands.
> Thus I would vote for only adding stuff already in pipeline and bug fixes in
> order to do a release in the next few weeks.

+1

In general releasing should not have to wait for patches to be
committed, and release time isn't the time to suddenly commit a bunch
of last minute patches.  It should rather be the reverse: right after
a release is when you should commit the big changes; this way they
have the most time to "bake" (uncovering issues) in trunk.

It's best if what's committed is always kept in a releasable state;
this way on any given morning someone could wake up and cut a release
candidate.

If there are truly blocker bugs then they should be marked that way in Jira...

Mike McCandless

http://blog.mikemccandless.com