Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of ohauer@gmx.de designates
 212.227.15.18 as permitted sender)
Message-ID: <51C5CDDE.1080103@gmx.de>
Date: Sat, 22 Jun 2013 18:16:30 +0200
From: olli hauer <ohauer@gmx.de>
Reply-To: APR Developer List <dev@apr.apache.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
 rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: APR Developer List <dev@apr.apache.org>
CC: "William A. Rowe Jr." <wrowe@rowe-clan.net>
Subject: Re: apr / apr-util roadmap
References: <51C5851B.3070706@gmx.de> <20130622100308.3227372d@hub>
In-Reply-To: <20130622100308.3227372d@hub>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 2013-06-22 17:03, William A. Rowe Jr. wrote:
> On Sat, 22 Jun 2013 13:06:03 +0200
> olli hauer <ohauer@gmx.de> wrote:
> 
>> Hi,
>>
>> is there a public roadmap for apr and apr-util?
>>
>> I remember I have read something like changing to cmake.
>>
>> Also in the past there where sometimes a apr-2 snapshot
>> where everything was delivered in one big distfile.
>> (I think apr_20110821151329 was the last)
>>
>> I'm interested in this details to draw a rad map for the
>> FreeBSD apr / apr-util / apache ports.
> 
> This is all discussed on this list, and changes with little
> debate are usually passed through the corresponding STATUS
> files in each branch.  There is no other active top level
> planning document at this time.

Thanks for pointing to the STATUS files.

> In the near term, no major changes are expected, and we are
> unlikely to rip out autoconf for those platforms where it works
> relatively well.  There are some new features in apr-2.0 (where
> apr-util has been folded into the same library) but not particular
> schedule for releasing that branch at this time, nor a schedule
> to release a new version-minor of 1.x of either apr or apr-util.
>
> Windows specific build files and scons support are likely to 
> be replaced by cmake in the near term, initially in apr-2.0 tree.
> It remains to be seen if this is worth applying to apr-1.x, or if
> we use that effort to drive 2.0 towards release.


OK, so it seems apr-1 and apr-utils will be around the next years.

For you as background why I ask:

For nearly a decade apr and apr-utils are handled on FreeBSD together
as a single port and we started a discussion to separate them into two
ports.

--
olli