commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] Release Commons VFS 2.0
Date Wed, 22 Dec 2010 13:11:09 GMT
On 22 December 2010 07:43, Jörg Schaible <joerg.schaible@scalaris.com> wrote:
> Hi,
>
> Phil Steitz wrote:
>
>> On Tue, Dec 21, 2010 at 7:48 PM, sebb <sebbaz@gmail.com> wrote:
>>
>>> On 22 December 2010 00:11, Phil Steitz <phil.steitz@gmail.com> wrote:
>>> > On Tue, Dec 21, 2010 at 7:00 PM, Ralph Goers
>>> > <ralph.goers@dslextreme.com
>>> >wrote:
>>> >
>>> >>
>>> >> On Dec 21, 2010, at 2:55 PM, sebb wrote:
>>> >>
>>> >> > On 21 December 2010 05:21, Ralph Goers <ralph.goers@dslextreme.com>
>>> >> wrote
>>> >> >
>>> >> >> I have not included release notes in the src zip since my
>>> understanding
>>> >> is the src zip should contain the directories pretty much as they
>>> >> exist
>>> in
>>> >> SVN.  Instead I have added a README.txt that tells a user how to
>>> generate
>>> >> the announcement file.
>>> >> >
>>> >> > I would prefer to see the release notes generated and checked into
>>> >> > SVN; they can then be included in both source and binary archives.
>>> >> >
>>> >> > See for example MATH and NET (2.0)
>>> >>
>>> >> I looked at net/trunk. I would prefer that the release notes be
>>> generated
>>> >> during mvn release:prepare instead of requiring a manual mvn
>>> >> invocation
>>> to
>>> >> create the release notes and then a commit. I have that working for
>>> >> the binary distribution but I don't want to do it for the source
>>> distribution
>>> >> since they shouldn't be included if they aren't in svn and, in my
>>> >> view,
>>> they
>>> >> shouldn't be in svn because they will generally be out of sync with
>>> >> changes.xml in trunk.
>>> >>
>>> >> I would say that is up to the RM :)
>>> >
>>> > I personally don't have a problem with the out-of-synch condition.
>>> > What
>>> is
>>> > important is, like changes.xml or any other file, what gets tagged and
>>> > released.
>>>
>>> +1
>>>
>>> I think it's vital that the release notes are included in the source
>>> release.
>>>
>>> The user should not be required to run a command to create the release
>>> notes.
>>>
>>> But the RM should definitely *look at* the generated release notes and,
>> IMO, intentionally committing them is a good thing.  Nothing generated
>> directly from maven has ever met my expectations in terms of formatting
>> and
>> content, so I have always ended up tweaking the generated files.

BTW, I did a bit of work with the MATH vm file which makes it possible
to produce better formatting, by adjusting the spacing in the
changes.xml file.

It's a bit tedious getting it correct initially but the output can
look quite acceptable.

Once set up, adding new entries is easy - just follow the existing spacing.

> > I don't see this as onerous, personally.

+1

> Then why not generating it directly before the release manually, "finalize"
> it and commit it? After a release it can be deleted again in svn.

Why delete it?

So long as the RN are uptodate for the release, it does not matter if
it gets a bit stale later.
Changes.xml is not always kept up to date between releases either.

> All we need then is a verification that the file exists while releasing.
> This can be done by the verifier plugin (best to bind the goal to the
> validation phase) in the release profile.

The verification that is needed is that changes.xml is uptodate, and
the RN file corresponds.

> - Jörg
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message