Niall Pemberton wrote:
> On 6/2/06, Henri Yandell <flamefew@gmail.com> wrote:
>> On 5/28/06, Dennis Lundberg <dennisl@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
|