Peter,
The proposal of Vincent's is a compromise. Slide currently depends on
httpclient code that would look much like the 1.0 release. If I
understand what Remy said yesterday, he would use the 1.0 if it plugged
straight into Slide. I am assuming that he and other Slide committers
want a 1.0 release, so that they could try and merge Rod's bug fixes
into a 1.1, without breaking their current API compatibility. The 2.0
branch would be maintained by Rod, Morgan and others in an attempt to be
as spec conformant as possible, without trying to remain 100% API
compatible.
Remy's position is that he _might_ change to a 2.0 if he sees major
benefit from it, and it is released and stable.
Scott
> Just a recomendation that you should feel free to ignore if
> you feel like ;)
>
> However I would suggest not doing a release and not changing
> slide just yet.
> Why? Because that means that you are releasing software that
> you know you
> wont be supporting in future, and has many bugs. Instead just
> refactor it
> completely and nicely.
>
> Then in the future have slide change *once* rather than twice
> and preferably
> provide adapter classes to bridge between two APIs. Remember
> users who have
> to suffer through a changing API are less likely to come back
> and IMHO it is
> better NOT to release something you know is buggy and you
> know you will not
> be supporting.
>
