You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Grobmeier <gr...@gmail.com> on 2009/04/14 15:37:36 UTC
[compress] Any more issues before release 1.0?
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
* The abstract CompressArchiveIn/OutputStreams do nothing and are
simply marker interfaces at the moment. Should we change them to
interfaces, sincce they are abstract?
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. :-)
Best,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Any more issues before release 1.0?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-04-14, Christian Grobmeier <gr...@gmail.com> wrote:
> 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?
62 will probably never be closed since you cannot have too many tests.
> I think 64 and 63 should be resolved before we release.
+1
> * There are several ideas for ChangeSet open, but it's marked
> experimental and the most important are included. Imho not necessary
> for 1.0
+1
> * The abstract CompressArchiveIn/OutputStreams do nothing and are
> simply marker interfaces at the moment. Should we change them to
> interfaces, sincce they are abstract?
They may prove to be useful later.
> 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. :-)
Thank you for volunteering. May
<http://wiki.apache.org/commons/CreatingReleases> be with you.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Any more issues before release 1.0?
Posted by sebb <se...@gmail.com>.
On 14/04/2009, Christian Grobmeier <gr...@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