serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Apache Serf 1.4.0 / 2.0.0 (and 1.3.9)
Date Wed, 07 Oct 2015 22:03:18 GMT
On Wed, Oct 7, 2015 at 6:30 AM, Bert Huijben <bert@qqmail.nl> wrote:

>         Hi all,
>
> I'll have to report progress to the ASF board in a few days, but I don't
> have much to add over the previous report.
>

Preparing a 1.3.x release, figuring out compatibility for a 1.4.x line, etc.

The Board is looking to whether the community is doing something, and is
doing it Properly. Heck, we could be doing nothing, and the Board would be
okay with that ... as long as we have ample oversight over that Nothing :-)

(eg. Apache Forrest hasn't done anything in years, but they have enough PMC
members to manage the operation of the (idle) project)


>
> I don't see a real solution yet on how we can release a Serf 1.4.0 soon.
> Greg's solution might work but it feels like another hack to me.


Of course it is a hack :-) ... but that's what is needed for 1.3.x
compatibility.


> When I
> talked to Ivan in Berlin we came to the conclusion that it might be easier
> to just go directly to Serf 2.0 and resolve the bucket problem properly
> (with a way for future extension) and get the thing released.
>
> Subversion 1.9 is already compatible with a Serf 2.0 -to allow testing
> against trunk- and I don't think it would be that hard for other users like
> Openoffice to enable support for that.
>

But we can do it without asking them to do *any* changes. The change is
quite simple (change a function pointer comparison to a helper function
call).

We can leave the config stuff in. I have no opinion on restoring the
get_remaining for 1.4.x, or to do that for 1.5.x. If somebody wants to do
the work, then fine. Also seems fine to leave it be, get 1.4.x out, and put
that stuff into 1.5.x.

Trunk should likely renumber itself to 1.x. I'll put my 2.0 breaking
changes (new protocols and connection typse) onto a branch.

>...

Cheers,
-g

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message