You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2006/05/28 09:03:53 UTC
[VOTE] Release FileUpload 1.1.1-RC1
I've prepared a release for FileUpload;
http://people.apache.org/~bayard/fileupload/
[ ] +1, looks good.
[ ] -1, nope, something needs fixing.
Will keep the vote open until Thursday (given that Monday is a holiday
for many).
[I haven't created an SVN tag for the RC1. Is there any particular
reason the release info says to create a tag?]
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Henri Yandell <fl...@gmail.com>.
On 6/2/06, Lukas Theussl <lt...@apache.org> wrote:
>
>
> >>
> >> The problem is that at the moment of the release, lastRelease should
> >> still mean the previous release but it doesn't. At that moment it
> >> suddenly means that release and you get a really small changelog.
> >
> >
> >
> > Well that's brilliant. I wonder if anyone can come up with a use case for
> > that behaviour... ;-)
> >
>
> Some background: I joined the Maven team just at a time when (almost)
> everybody abandoned m1 and concentrated on m2 development, leaving
> behind some 65 plugins in an unmaintained and half-finished state. So my
> usecase was that this option allowed me to view at a glance what had
> been worked on still after each last release, without having to look up,
> and manually fill in, the release dates for each of these ~65 plugins.
>
> It was never meant to be used 'in production' though, as a
> well-maintained project with a responsible RM should always have these
> dates up-to-date (which means: set at release time). Or do you think
> that a 'nextToLastRelease' option would be reasonable? :)
Other option would be for 'maven site' to be a part of the release
plugin in m2 (not sure if it is) and for plugins to therefore know
they're running within a release context and not a dev context.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Lukas Theussl <lt...@apache.org>.
>>
>> The problem is that at the moment of the release, lastRelease should
>> still mean the previous release but it doesn't. At that moment it
>> suddenly means that release and you get a really small changelog.
>
>
>
> Well that's brilliant. I wonder if anyone can come up with a use case for
> that behaviour... ;-)
>
Some background: I joined the Maven team just at a time when (almost)
everybody abandoned m1 and concentrated on m2 development, leaving
behind some 65 plugins in an unmaintained and half-finished state. So my
usecase was that this option allowed me to view at a glance what had
been worked on still after each last release, without having to look up,
and manually fill in, the release dates for each of these ~65 plugins.
It was never meant to be used 'in production' though, as a
well-maintained project with a responsible RM should always have these
dates up-to-date (which means: set at release time). Or do you think
that a 'nextToLastRelease' option would be reasonable? :)
Cheers,
-Lukas
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Martin Cooper <ma...@apache.org>.
On 6/2/06, Henri Yandell <fl...@gmail.com> wrote:
>
> On 6/2/06, Martin Cooper <ma...@apache.org> wrote:
> > On 6/2/06, Niall Pemberton <ni...@gmail.com> wrote:
> > >
> > > On 6/2/06, Henri Yandell <fl...@gmail.com> wrote:
> > > > On 5/28/06, Dennis Lundberg <de...@apache.org> wrote:
> > > > > In version 1.9 of the changelog-plugin a new option was added that
> > > might
> > > > > solve this problem. Add these lines to the project.propertiesfile:
> > > > >
> > > > > maven.changelog.date=lastRelease
> > > > > maven.changelog.type=date
> > > > >
> > > > > The plugin looks in the changes.xml file to find the previous
> release.
> > > > > Fileupload has such a file so that's good. I tried this on
> fileupload
> > > > > and the plugin choked because of an unparseable date "2006-05-??",
> > > which
> > > > > is the date set for the 1.1.1 release. So I changed that date to
> "In
> > > > > SVN" and ran maven site again and the plugin correctly picked up
> > > > > "2005-12-24" from the 1.1 release.
> > > >
> > > > This does work, though it means the changes report has In SVN in and
> > > > not the date. Still, I can generate this to get that page and put it
> > > > in later on the main build.
> > > >
> > > > Any objections to that?
> > >
> > > Yes its messy and liable to go wrong when you forget to do something
> > > when cutting the actual release.
> >
> >
> > Given that you're never going to know the actual release date until
> you're
> > actually cutting the release, the date in the change log will _always_
> have
> > to be updated by the RM at that time. It wouldn't be any worse to have
> "In
> > SVN" than "2006-05-??" (especially given that it's now June ;). I used
> to
> > use "Pending" for the date value until I cut the release.
> >
> > And it seems to me that using "lastRelease" is always correct, so that
> seems
> > like the right value to use. I just didn't know about it until Dennis
> > mentioned it.
>
> The problem is that at the moment of the release, lastRelease should
> still mean the previous release but it doesn't. At that moment it
> suddenly means that release and you get a really small changelog.
Well that's brilliant. I wonder if anyone can come up with a use case for
that behaviour... ;-)
--
Martin Cooper
Easiest solution is for the release manager to change
> project.properties to list the lastRelease date just prior to building
> the release as Niall suggested.
>
> (Well, easiest easiest would be to dump the report as too much trouble
> ;) )
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Henri Yandell <fl...@gmail.com>.
On 6/2/06, Martin Cooper <ma...@apache.org> wrote:
> On 6/2/06, Niall Pemberton <ni...@gmail.com> wrote:
> >
> > On 6/2/06, Henri Yandell <fl...@gmail.com> wrote:
> > > On 5/28/06, Dennis Lundberg <de...@apache.org> wrote:
> > > > In version 1.9 of the changelog-plugin a new option was added that
> > might
> > > > solve this problem. Add these lines to the project.properties file:
> > > >
> > > > maven.changelog.date=lastRelease
> > > > maven.changelog.type=date
> > > >
> > > > The plugin looks in the changes.xml file to find the previous release.
> > > > Fileupload has such a file so that's good. I tried this on fileupload
> > > > and the plugin choked because of an unparseable date "2006-05-??",
> > which
> > > > is the date set for the 1.1.1 release. So I changed that date to "In
> > > > SVN" and ran maven site again and the plugin correctly picked up
> > > > "2005-12-24" from the 1.1 release.
> > >
> > > This does work, though it means the changes report has In SVN in and
> > > not the date. Still, I can generate this to get that page and put it
> > > in later on the main build.
> > >
> > > Any objections to that?
> >
> > Yes its messy and liable to go wrong when you forget to do something
> > when cutting the actual release.
>
>
> Given that you're never going to know the actual release date until you're
> actually cutting the release, the date in the change log will _always_ have
> to be updated by the RM at that time. It wouldn't be any worse to have "In
> SVN" than "2006-05-??" (especially given that it's now June ;). I used to
> use "Pending" for the date value until I cut the release.
>
> And it seems to me that using "lastRelease" is always correct, so that seems
> like the right value to use. I just didn't know about it until Dennis
> mentioned it.
The problem is that at the moment of the release, lastRelease should
still mean the previous release but it doesn't. At that moment it
suddenly means that release and you get a really small changelog.
Easiest solution is for the release manager to change
project.properties to list the lastRelease date just prior to building
the release as Niall suggested.
(Well, easiest easiest would be to dump the report as too much trouble ;) )
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Martin Cooper <ma...@apache.org>.
On 6/2/06, Niall Pemberton <ni...@gmail.com> wrote:
>
> On 6/2/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 5/28/06, Dennis Lundberg <de...@apache.org> wrote:
> > > In version 1.9 of the changelog-plugin a new option was added that
> might
> > > solve this problem. Add these lines to the project.properties file:
> > >
> > > maven.changelog.date=lastRelease
> > > maven.changelog.type=date
> > >
> > > The plugin looks in the changes.xml file to find the previous release.
> > > Fileupload has such a file so that's good. I tried this on fileupload
> > > and the plugin choked because of an unparseable date "2006-05-??",
> which
> > > is the date set for the 1.1.1 release. So I changed that date to "In
> > > SVN" and ran maven site again and the plugin correctly picked up
> > > "2005-12-24" from the 1.1 release.
> >
> > This does work, though it means the changes report has In SVN in and
> > not the date. Still, I can generate this to get that page and put it
> > in later on the main build.
> >
> > Any objections to that?
>
> Yes its messy and liable to go wrong when you forget to do something
> when cutting the actual release.
Given that you're never going to know the actual release date until you're
actually cutting the release, the date in the change log will _always_ have
to be updated by the RM at that time. It wouldn't be any worse to have "In
SVN" than "2006-05-??" (especially given that it's now June ;). I used to
use "Pending" for the date value until I cut the release.
And it seems to me that using "lastRelease" is always correct, so that seems
like the right value to use. I just didn't know about it until Dennis
mentioned it.
You know that you can override
> settings if you have a local "build.properties" file? Better to just
> override this locally with the actual date:
>
> maven.changelog.date=2005-12-24
>
> That way you can put the proper release date back into the changes file.
But you'll never know what that date is until you're actually cutting the
release, so what are you going to put there before you're in the process of
rolling it?
--
Martin Cooper
Niall
>
> > I've uploaded the new page to the rc1 site:
> >
> > http://people.apache.org/~bayard/fileupload/docs/changelog-report.html
> >
> > Does that resolve the problem satisfactorily?
> >
> > Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Martin Cooper <ma...@apache.org>.
On 6/3/06, Henri Yandell <fl...@gmail.com> wrote:
>
> On 6/2/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 6/2/06, Niall Pemberton <ni...@gmail.com> wrote:
> > > maven.changelog.date=2005-12-24
> > >
> > > That way you can put the proper release date back into the changes
> file.
> >
> > Much better. I'll do so and replace the docs with a new docs directory.
> >
>
> Have done this. So the process is:
>
> svn co
> edit build.properties to contain the 2nd to last date instead of
> lastRelease
> cut release
>
> There are other things you have to do in there too (commit a change to
> the doap file, put the final date in the site and changes) so it's not
> as if it's the only thing.
>
> Does this new changelog look okay?
Yep, it looks like everything is in there now.
--
Martin Cooper
If so I'll start the vote on RC1
> again as we've had a lot of noise on this thread.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Henri Yandell <fl...@gmail.com>.
On 6/2/06, Henri Yandell <fl...@gmail.com> wrote:
> On 6/2/06, Niall Pemberton <ni...@gmail.com> wrote:
> > maven.changelog.date=2005-12-24
> >
> > That way you can put the proper release date back into the changes file.
>
> Much better. I'll do so and replace the docs with a new docs directory.
>
Have done this. So the process is:
svn co
edit build.properties to contain the 2nd to last date instead of lastRelease
cut release
There are other things you have to do in there too (commit a change to
the doap file, put the final date in the site and changes) so it's not
as if it's the only thing.
Does this new changelog look okay? If so I'll start the vote on RC1
again as we've had a lot of noise on this thread.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Henri Yandell <fl...@gmail.com>.
On 6/2/06, Niall Pemberton <ni...@gmail.com> wrote:
> On 6/2/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 5/28/06, Dennis Lundberg <de...@apache.org> wrote:
> > > In version 1.9 of the changelog-plugin a new option was added that might
> > > solve this problem. Add these lines to the project.properties file:
> > >
> > > maven.changelog.date=lastRelease
> > > maven.changelog.type=date
> > >
> > > The plugin looks in the changes.xml file to find the previous release.
> > > Fileupload has such a file so that's good. I tried this on fileupload
> > > and the plugin choked because of an unparseable date "2006-05-??", which
> > > is the date set for the 1.1.1 release. So I changed that date to "In
> > > SVN" and ran maven site again and the plugin correctly picked up
> > > "2005-12-24" from the 1.1 release.
> >
> > This does work, though it means the changes report has In SVN in and
> > not the date. Still, I can generate this to get that page and put it
> > in later on the main build.
> >
> > Any objections to that?
>
> Yes its messy and liable to go wrong when you forget to do something
> when cutting the actual release. You know that you can override
> settings if you have a local "build.properties" file? Better to just
> override this locally with the actual date:
>
> maven.changelog.date=2005-12-24
>
> That way you can put the proper release date back into the changes file.
Much better. I'll do so and replace the docs with a new docs directory.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Henri Yandell <fl...@gmail.com>.
To me this is just window dressing and it's just irritating that it
means an SVN change. I'm not inclined to make a new RC just for the
changelog tweaks and so - yes, please have a look at the RC :)
Hen
On 6/2/06, Rahul Akolkar <ra...@gmail.com> wrote:
> Is this a good time to check the RC? Unclear (to me) whether the
> changelog discussion is a non-maskable interrupt.
>
> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Rahul Akolkar <ra...@gmail.com>.
Is this a good time to check the RC? Unclear (to me) whether the
changelog discussion is a non-maskable interrupt.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On 6/2/06, Henri Yandell <fl...@gmail.com> wrote:
>> On 5/28/06, Dennis Lundberg <de...@apache.org> wrote:
>> > In version 1.9 of the changelog-plugin a new option was added that
>> might
>> > solve this problem. Add these lines to the project.properties file:
>> >
>> > maven.changelog.date=lastRelease
>> > maven.changelog.type=date
>> >
>> > The plugin looks in the changes.xml file to find the previous release.
>> > Fileupload has such a file so that's good. I tried this on fileupload
>> > and the plugin choked because of an unparseable date "2006-05-??",
>> which
>> > is the date set for the 1.1.1 release. So I changed that date to "In
>> > SVN" and ran maven site again and the plugin correctly picked up
>> > "2005-12-24" from the 1.1 release.
>>
>> This does work, though it means the changes report has In SVN in and
>> not the date. Still, I can generate this to get that page and put it
>> in later on the main build.
>>
>> Any objections to that?
>
> Yes its messy and liable to go wrong when you forget to do something
> when cutting the actual release. You know that you can override
> settings if you have a local "build.properties" file? Better to just
> override this locally with the actual date:
>
> maven.changelog.date=2005-12-24
>
> That way you can put the proper release date back into the changes file.
If you use Maven to cut the release (maven scm:prepare-release) it
actually finds the non-date ("In SVN") in changes.xml, alters its value
to the current date and checks that change into SVN, prior to tagging
the release.
<snip>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Niall Pemberton <ni...@gmail.com>.
On 6/2/06, Henri Yandell <fl...@gmail.com> wrote:
> On 5/28/06, Dennis Lundberg <de...@apache.org> wrote:
> > In version 1.9 of the changelog-plugin a new option was added that might
> > solve this problem. Add these lines to the project.properties file:
> >
> > maven.changelog.date=lastRelease
> > maven.changelog.type=date
> >
> > The plugin looks in the changes.xml file to find the previous release.
> > Fileupload has such a file so that's good. I tried this on fileupload
> > and the plugin choked because of an unparseable date "2006-05-??", which
> > is the date set for the 1.1.1 release. So I changed that date to "In
> > SVN" and ran maven site again and the plugin correctly picked up
> > "2005-12-24" from the 1.1 release.
>
> This does work, though it means the changes report has In SVN in and
> not the date. Still, I can generate this to get that page and put it
> in later on the main build.
>
> Any objections to that?
Yes its messy and liable to go wrong when you forget to do something
when cutting the actual release. You know that you can override
settings if you have a local "build.properties" file? Better to just
override this locally with the actual date:
maven.changelog.date=2005-12-24
That way you can put the proper release date back into the changes file.
Niall
> I've uploaded the new page to the rc1 site:
>
> http://people.apache.org/~bayard/fileupload/docs/changelog-report.html
>
> Does that resolve the problem satisfactorily?
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Henri Yandell <fl...@gmail.com>.
On 5/28/06, Dennis Lundberg <de...@apache.org> wrote:
> In version 1.9 of the changelog-plugin a new option was added that might
> solve this problem. Add these lines to the project.properties file:
>
> maven.changelog.date=lastRelease
> maven.changelog.type=date
>
> The plugin looks in the changes.xml file to find the previous release.
> Fileupload has such a file so that's good. I tried this on fileupload
> and the plugin choked because of an unparseable date "2006-05-??", which
> is the date set for the 1.1.1 release. So I changed that date to "In
> SVN" and ran maven site again and the plugin correctly picked up
> "2005-12-24" from the 1.1 release.
This does work, though it means the changes report has In SVN in and
not the date. Still, I can generate this to get that page and put it
in later on the main build.
Any objections to that?
I've uploaded the new page to the rc1 site:
http://people.apache.org/~bayard/fileupload/docs/changelog-report.html
Does that resolve the problem satisfactorily?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Dennis Lundberg <de...@apache.org>.
Martin Cooper wrote:
> On 5/28/06, Henri Yandell <fl...@gmail.com> wrote:
>>
>> Sorry, habit.
>>
>> +1
>>
>> I remember Martin having pain with changelogs and things last time, so
>> if you or Martin remember what they were exactly that would be a good
>> thing to check. I couldn't see any obvious issues looking at the
>> report.
>
>
> The problem is that it's picking up only the last 30 days of commits,
> instead of all of the changes since the 1.1 release. In this case, it
> doesn't even seem to have done that, since it's missed both of the bug
> fixes
> that we're doing this release for. ;-( (The second of those was checked in
> early this month, but it was still missed.)
>
> For the last release, I used a patched version of the Maven plugin that
> Niall built to fix this. I'm not sure if the plugin itself has been fixed
> since then, though, in which case all we'd need to do is change config for
> it.
In version 1.9 of the changelog-plugin a new option was added that might
solve this problem. Add these lines to the project.properties file:
maven.changelog.date=lastRelease
maven.changelog.type=date
The plugin looks in the changes.xml file to find the previous release.
Fileupload has such a file so that's good. I tried this on fileupload
and the plugin choked because of an unparseable date "2006-05-??", which
is the date set for the 1.1.1 release. So I changed that date to "In
SVN" and ran maven site again and the plugin correctly picked up
"2005-12-24" from the 1.1 release.
The version we have listed for the changelog-plugin in
commons-build/pluginUpdate.txt is 1.8.2. The latest released version,
which is the one I used in my test, is 1.9.1. Perhaps it's time to
upgrade to 1.9.1?
> A couple of other minor things I noticed: I'm guessing you built on a *nix
> box, because the license and notice files have those line ends, which means
> they don't come up right in notepad on Windows. And the manifest file says
> it was built by "hen" - although around here we all know who "hen" is. ;-)
>
> --
> Martin Cooper
>
>
> Hen
>>
>> On 5/28/06, Niall Pemberton <ni...@gmail.com> wrote:
>> > +1 from me.
>> >
>> > All looks good to me - builds fine from the source distro and I tried
>> > the jar in my webapp with no problems (and saw the lowercase filenames
>> > bug fixed).
>> >
>> > Niall
>> >
>> > P.S. Henri are you going to vote?
>> >
>> > On 5/28/06, Henri Yandell <fl...@gmail.com> wrote:
>> > > I've prepared a release for FileUpload;
>> > >
>> > > http://people.apache.org/~bayard/fileupload/
>> > >
>> > > [ ] +1, looks good.
>> > > [ ] -1, nope, something needs fixing.
>> > >
>> > >
>> > > Will keep the vote open until Thursday (given that Monday is a
>> holiday
>> > > for many).
>> > >
>> > > [I haven't created an SVN tag for the RC1. Is there any particular
>> > > reason the release info says to create a tag?]
>> > >
>> > > Hen
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Niall Pemberton <ni...@gmail.com>.
On 5/28/06, Martin Cooper <ma...@apache.org> wrote:
> On 5/28/06, Henri Yandell <fl...@gmail.com> wrote:
> >
> > Sorry, habit.
> >
> > +1
> >
> > I remember Martin having pain with changelogs and things last time, so
> > if you or Martin remember what they were exactly that would be a good
> > thing to check. I couldn't see any obvious issues looking at the
> > report.
>
>
> The problem is that it's picking up only the last 30 days of commits,
> instead of all of the changes since the 1.1 release. In this case, it
> doesn't even seem to have done that, since it's missed both of the bug fixes
> that we're doing this release for. ;-( (The second of those was checked in
> early this month, but it was still missed.)
>
> For the last release, I used a patched version of the Maven plugin that
> Niall built to fix this. I'm not sure if the plugin itself has been fixed
> since then, though, in which case all we'd need to do is change config for
> it.
AFAIK its still not fixed - patch available for version 1.8.2 of
changelog plugin is here:
http://www.niallp.pwp.blueyonder.co.uk/ChangelogSubversionIssue.html
Niall
> A couple of other minor things I noticed: I'm guessing you built on a *nix
> box, because the license and notice files have those line ends, which means
> they don't come up right in notepad on Windows. And the manifest file says
> it was built by "hen" - although around here we all know who "hen" is. ;-)
>
> --
> Martin Cooper
>
>
> Hen
> >
> > On 5/28/06, Niall Pemberton <ni...@gmail.com> wrote:
> > > +1 from me.
> > >
> > > All looks good to me - builds fine from the source distro and I tried
> > > the jar in my webapp with no problems (and saw the lowercase filenames
> > > bug fixed).
> > >
> > > Niall
> > >
> > > P.S. Henri are you going to vote?
> > >
> > > On 5/28/06, Henri Yandell <fl...@gmail.com> wrote:
> > > > I've prepared a release for FileUpload;
> > > >
> > > > http://people.apache.org/~bayard/fileupload/
> > > >
> > > > [ ] +1, looks good.
> > > > [ ] -1, nope, something needs fixing.
> > > >
> > > >
> > > > Will keep the vote open until Thursday (given that Monday is a holiday
> > > > for many).
> > > >
> > > > [I haven't created an SVN tag for the RC1. Is there any particular
> > > > reason the release info says to create a tag?]
> > > >
> > > > Hen
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Martin Cooper <ma...@apache.org>.
On 5/28/06, Henri Yandell <fl...@gmail.com> wrote:
>
> Sorry, habit.
>
> +1
>
> I remember Martin having pain with changelogs and things last time, so
> if you or Martin remember what they were exactly that would be a good
> thing to check. I couldn't see any obvious issues looking at the
> report.
The problem is that it's picking up only the last 30 days of commits,
instead of all of the changes since the 1.1 release. In this case, it
doesn't even seem to have done that, since it's missed both of the bug fixes
that we're doing this release for. ;-( (The second of those was checked in
early this month, but it was still missed.)
For the last release, I used a patched version of the Maven plugin that
Niall built to fix this. I'm not sure if the plugin itself has been fixed
since then, though, in which case all we'd need to do is change config for
it.
A couple of other minor things I noticed: I'm guessing you built on a *nix
box, because the license and notice files have those line ends, which means
they don't come up right in notepad on Windows. And the manifest file says
it was built by "hen" - although around here we all know who "hen" is. ;-)
--
Martin Cooper
Hen
>
> On 5/28/06, Niall Pemberton <ni...@gmail.com> wrote:
> > +1 from me.
> >
> > All looks good to me - builds fine from the source distro and I tried
> > the jar in my webapp with no problems (and saw the lowercase filenames
> > bug fixed).
> >
> > Niall
> >
> > P.S. Henri are you going to vote?
> >
> > On 5/28/06, Henri Yandell <fl...@gmail.com> wrote:
> > > I've prepared a release for FileUpload;
> > >
> > > http://people.apache.org/~bayard/fileupload/
> > >
> > > [ ] +1, looks good.
> > > [ ] -1, nope, something needs fixing.
> > >
> > >
> > > Will keep the vote open until Thursday (given that Monday is a holiday
> > > for many).
> > >
> > > [I haven't created an SVN tag for the RC1. Is there any particular
> > > reason the release info says to create a tag?]
> > >
> > > Hen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Henri Yandell <fl...@gmail.com>.
Sorry, habit.
+1
I remember Martin having pain with changelogs and things last time, so
if you or Martin remember what they were exactly that would be a good
thing to check. I couldn't see any obvious issues looking at the
report.
Hen
On 5/28/06, Niall Pemberton <ni...@gmail.com> wrote:
> +1 from me.
>
> All looks good to me - builds fine from the source distro and I tried
> the jar in my webapp with no problems (and saw the lowercase filenames
> bug fixed).
>
> Niall
>
> P.S. Henri are you going to vote?
>
> On 5/28/06, Henri Yandell <fl...@gmail.com> wrote:
> > I've prepared a release for FileUpload;
> >
> > http://people.apache.org/~bayard/fileupload/
> >
> > [ ] +1, looks good.
> > [ ] -1, nope, something needs fixing.
> >
> >
> > Will keep the vote open until Thursday (given that Monday is a holiday
> > for many).
> >
> > [I haven't created an SVN tag for the RC1. Is there any particular
> > reason the release info says to create a tag?]
> >
> > Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VOTE] Release FileUpload 1.1.1-RC1
Posted by Niall Pemberton <ni...@gmail.com>.
+1 from me.
All looks good to me - builds fine from the source distro and I tried
the jar in my webapp with no problems (and saw the lowercase filenames
bug fixed).
Niall
P.S. Henri are you going to vote?
On 5/28/06, Henri Yandell <fl...@gmail.com> wrote:
> I've prepared a release for FileUpload;
>
> http://people.apache.org/~bayard/fileupload/
>
> [ ] +1, looks good.
> [ ] -1, nope, something needs fixing.
>
>
> Will keep the vote open until Thursday (given that Monday is a holiday
> for many).
>
> [I haven't created an SVN tag for the RC1. Is there any particular
> reason the release info says to create a tag?]
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org