On 14/04/2009, Christian Grobmeier <grobme...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
