Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.128.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Wd+eRaOH8dEdIWknn1GlXduFe62exW4PbrtH+feHHqITkRcYN6N2QcNI0HSb+mIQ52
         vAkDIe9/SmHScTVYCA47EN3ANdPke1PGYxrlVc6+bNWQU+K+oqnl3qVOLHUc6y540itM
         4um4sWr/sGHiGCRZuWCiBwUPDNUkh/Dmv9WP8=
MIME-Version: 1.0
In-Reply-To: <ded132f10904140637m4e5ae06fo505dc98ff4d481c@mail.gmail.com>
References: <ded132f10904140637m4e5ae06fo505dc98ff4d481c@mail.gmail.com>
Date: Tue, 14 Apr 2009 14:56:26 +0100
Message-ID: <25aac9fc0904140656y6eb69e54qb44260e43cbd8251@mail.gmail.com>
Subject: Re: [compress] Any more issues before release 1.0?
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 14/04/2009, Christian Grobmeier <grobmeier@gmail.com> wrote:
> Hi all,
>
>  today we have resolved all remaining issues in Jira.
>  Open and unscheduled Issues are:
>
>  * COMPRESS-62            Need many more test cases to check that can read
>  "real" archives
>  * COMPRESS-64   Are the public finish() methods ArchiveOutputStream
>  implementations necessary and safe?
>  * COMPRESS-63   String#getBytes() is platform dependent
>  * COMPRESS-54   Add 7zip or RAR archive support
>
>  Should we schedule any issues before 1.0?
>  I think 64 and 63 should be resolved before we release.
>
>  * There are several ideas for ChangeSet open, but it's marked
>  experimental and the most important are included. Imho not necessary
>  for 1.0

Agreed.

>  * The abstract CompressArchiveIn/OutputStreams do nothing and are
>  simply marker interfaces at the moment. Should we change them to
>  interfaces, sincce they are abstract?

I think these could be useful as abstract classes. For example if we
want to add input stream byte counting (for use in Exceptions) this
could be done by storing the input stream in the class, but wrapped in
a counting stream.

>  All the other stuff looks complete and I think we should think on a
>  release soon. I don't have any expierence with releasing at apache,
>  but I am willing to read, learn and do it finally. :-)

The first release is different from other releases, in that there is
no need for compatibility with prior releases. Are we positive that
the API is as good as we can make it? Do all the methods, fields and
classes have the correct visibility, so should some be made protected
or private before it is too late? It's easy to make something more
visible later, but the reverse would mean making the API incompatible,
which is something to be avoided.

>  Best,
>  Christian
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org