I agree * wait until we have enough important changes for a solid point zero
release and break binary compatibility at that point.
Or have a release now and then say no more binary compatibility for next
version but there might be patches for this release if any bug needs fixing.
That way you can start new API if required and still support this.
Re
We cannot do that without breaking full binary compatibility with 4.0.x
releases. As much as I consider binary compatibility for non trivial
changes utterly pointless, I still think we should not break
compatibility without a good reason. All these classes are not meant to
be thread-safe, so mutability of instance variables is not really an
issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
