You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2006/03/05 02:28:22 UTC
[io] Release 1.2
I am proposing that we release [io] v1.2
RC1 is here:
http://people.apache.org/~scolebourne/commons-io/
Site here:
http://people.apache.org/~scolebourne/commons-io/site/
Not that much has changed (line iterator, two more filters, copy
directory), but its nice to release early for once.
Any objections, otherwise it'll move to a vote based on these files.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Release 1.2
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Rahul Akolkar wrote:
> How many releases back should we document online? In other words,
> should we have documentation sections for 1.0, 1.1 and 1.2?
My intent is for there to be javadoc for all releases on the server, but
links will only be provided for the latest, previous and SVN.
Directory structure
api-1.0 - v1.0
api-1.1 - v1.1
api-1.2 - v1.2
apidocs - svn latest
api-release - soft link to api-1.2
Left navigation
Link to latest version
Link to svn latest
Main overview page
Link to latest version
Link to previous version
Link to svn latest
All other files are svn latest only
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Release 1.2
Posted by Henri Yandell <fl...@gmail.com>.
On 3/4/06, Rahul Akolkar <ra...@gmail.com> wrote:
> On 3/4/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > I am proposing that we release [io] v1.2
> >
> > RC1 is here:
> > http://people.apache.org/~scolebourne/commons-io/
> >
> > Site here:
> > http://people.apache.org/~scolebourne/commons-io/site/
> >
> <snip/>
>
> How many releases back should we document online? In other words,
> should we have documentation sections for 1.0, 1.1 and 1.2?
We should be publishing documentation on every release that has a
downloadable release - which hopefully means every release. Bugfixes
should arguably be skipped - though we'd still need to find a way to
have their release notes integrated into the relevant minor version
release.
> Haven't checked the RC, but agree to early releasing. Thanks for taking this on.
Ditto. Will check it out tomorrow and get back to you.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Release 1.2
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/4/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> I am proposing that we release [io] v1.2
>
> RC1 is here:
> http://people.apache.org/~scolebourne/commons-io/
>
> Site here:
> http://people.apache.org/~scolebourne/commons-io/site/
>
<snip/>
How many releases back should we document online? In other words,
should we have documentation sections for 1.0, 1.1 and 1.2?
Haven't checked the RC, but agree to early releasing. Thanks for taking this on.
-Rahul
> Not that much has changed (line iterator, two more filters, copy
> directory), but its nice to release early for once.
>
>
> Any objections, otherwise it'll move to a vote based on these files.
>
> Stephen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Release 1.2
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Henri Yandell wrote:
> Is it intentional for the source to contain the binary jar?
Yes. Guarantees a correct JDK built jar.
> Noticed that the binary dists (and previous release of io) put the
> javadoc in docs/*. Others seem to do it in docs/api/*. Yet more do it
> in docs/apidocs/* if memory serves. No idea if we want to standardise
> that.
I suspect that this is a minor point in our current debates.
> Do we not keep release notes for various versions on the site? Also,
> why 'upgrade notes' instead of release notes?
The upgrade notes are the release notes.
> The JDiff report says the the diff is between 1_1 and CURRENT. I
> presume that would become 1_1 and 1_2 when you start tagging. The
> added pages on the JDiff report point to c:\ and not to http:...
Actually, unless you regen JDiff after tagging you don't get this. And
I've never managed to get Jdiff to link docs correctly. I'll probably
take jdiff offline.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Release 1.2
Posted by Henri Yandell <fl...@gmail.com>.
On 3/4/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> I am proposing that we release [io] v1.2
>
> RC1 is here:
> http://people.apache.org/~scolebourne/commons-io/
Is it intentional for the source to contain the binary jar?
>
> Site here:
> http://people.apache.org/~scolebourne/commons-io/site/
http://people.apache.org/~scolebourne/commons-io/site/checkstyle-report.html
indicates a few easy things to fix up (I think). Otherwise the site
looks fine I guess.
Noticed that the binary dists (and previous release of io) put the
javadoc in docs/*. Others seem to do it in docs/api/*. Yet more do it
in docs/apidocs/* if memory serves. No idea if we want to standardise
that.
md5's are correct.
I think the PGP stuff checked out. PGP exploded in errors trying to
import the IO file; GPG managed it though and I've been advised to use
GPG as PGP is crap. Verifying said that things were fine, though said
that it couldn't confirm if the key belonged to you.
Do we not keep release notes for various versions on the site? Also,
why 'upgrade notes' instead of release notes?
The JDiff report says the the diff is between 1_1 and CURRENT. I
presume that would become 1_1 and 1_2 when you start tagging. The
added pages on the JDiff report point to c:\ and not to http:...
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] LineIterator finalize
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Sandy McArthur wrote:
> Okay, but once the LineIterator instance is no longer strongly
> reachable it will be garbage collected. This will then make the Reader
> instance no longer strongly reachable and it will be garbage
> collected. When the Reader instance is collected then there are no
> leaked resources.
OK, that makes sense. By OO encapsulation, let the reader deal with it.
Sandy McArthur wrote:
>>>I don't think LineIterator should have a finalizer method and I
>>>believe the JavaDocs in that class about resource leaks are wrong and
>>>unnecessarily alarming.
How is the javadoc over the top? I'll happily make changes, or go ahead
yourself.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] LineIterator finalize
Posted by Sandy McArthur <sa...@apache.org>.
On 3/5/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Sandy McArthur wrote:
> > I don't think LineIterator should have a finalizer method and I
> > believe the JavaDocs in that class about resource leaks are wrong and
> > unnecessarily alarming.
>
> Here is the problem as I see it.
>
> Create a LineIterator.
> Start using it.
> An exception is thrown.
> The LineIterator is not closed.
>
> (assumes the user doesn't write the finally clause as the javadoc tells
> them to)
>
> This would appear to be a resource leak situation, as the underlying
> reader, which the iterator wraps, is still open.
Okay, but once the LineIterator instance is no longer strongly
reachable it will be garbage collected. This will then make the Reader
instance no longer strongly reachable and it will be garbage
collected. When the Reader instance is collected then there are no
leaked resources.
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[io] LineIterator finalize
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Sandy McArthur wrote:
> I don't think LineIterator should have a finalizer method and I
> believe the JavaDocs in that class about resource leaks are wrong and
> unnecessarily alarming.
Here is the problem as I see it.
Create a LineIterator.
Start using it.
An exception is thrown.
The LineIterator is not closed.
(assumes the user doesn't write the finally clause as the javadoc tells
them to)
This would appear to be a resource leak situation, as the underlying
reader, which the iterator wraps, is still open.
If you have a better solution, I'd love to hear it, as I don't like the
finalize method especially. (Feel free to commit to [io])
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Release 1.2
Posted by Sandy McArthur <sa...@gmail.com>.
On 3/4/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> I am proposing that we release [io] v1.2
>
> Not that much has changed (line iterator, two more filters, copy
> directory), but its nice to release early for once.
>
> Any objections, otherwise it'll move to a vote based on these files.
I don't think LineIterator should have a finalizer method and I
believe the JavaDocs in that class about resource leaks are wrong and
unnecessarily alarming.
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org