Thanks. I'll give it a whirl. We're using Hudson, presently. It's not
the pulling JIRA information that I think is going to give me issues,
though. It's that the changes.xml will have version "1.0.0" but the
current version from the CI point of view is "1.0.0-SNAPSHOT". Unless
the changes plug
On Wed, Nov 18, 2009 at 1:46 PM, David C. Hicks wrote:
> Of course...the build will break after a release because the new
> changes.xml won't have a section for the new release version.
> Come to think of it, will that even work? Since the CI sees a SNAPSHOT
> version, and the changes.xml doesn't
Of course...the build will break after a release because the new
changes.xml won't have a section for the new release version.
Come to think of it, will that even work? Since the CI sees a SNAPSHOT
version, and the changes.xml doesn't include SNAPSHOT.
David C. Hicks wrote:
> Good suggestion. I
Good suggestion. I hadn't really thought of using CI to test the
changes.xml. That's primarily because I also have the dependencies
report generated as part of the Site generation. Under normal
circumstances, it takes forever and a day to generate the dependencies
report, since it appears to hit
Changes plugin offers Jira and Trac integration. You can filter your
changes.xml if you cannot use current version only. Use ci system to
run the site and changes report so you know if it'll work or not
before the release.
Kalle
On Wed, Nov 18, 2009 at 12:56 PM, David C. Hicks wrote:
> Hi folks,
Hi folks,
I'm using the Changes plugin to both produce a report for my Site and to
distribute email announcements of changes. The problem is that if we're
not careful to remember to update the changes.xml file itself, then our
release build fails because it doesn't find a change set with the righ
