Rely on JIRA for release notes ?
Cantor, Scott
cantor.2 at osu.edu
Tue Jul 22 17:45:17 EDT 2014
On 7/22/14, 5:23 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>I guess my question is : should we rely on JIRA for generation of
>RELEASE-NOTES.txt ?
I do, but with a caveat.
>For example, there are no issues in JIRA for Spring Extensions for
>whatever version comes after the current release 1.2.0, but we
>actually added to the API according to Subversion :
>
> svn log https://svn.shibboleth.net/utilities/spring-extensions -rHEAD:608
>
> Support both string and boolean to Predicate conversions.
> JSPT-46 Move services down from the IdP...
I primarily use the release notes to identify bug fixes or changes, but
not necessarily try and document every new API. The main reason for that
is that the libraries are a secondary deliverable in this project, and to
invest the time needed to treat them as a primary deliverable is something
I consider a roadmap item. Until I'm told to spend my time there, and
divert it from other things, it's best effort, nothing more.
>So, I think we need to bump the minor version from 1.2.0 to 1.3.0
>because we added to the API, but the release notes generated by JIRA
>for Spring Extensions will not include JSPT-46 since that is in the
>Java Support project obviously. Of course, I can just manually copy
>the one-line JSP-46 issue to the release notes for Spring Extensions
>from Java Support, but I was wondering if we should generate
>RELEASE-NOTES.txt from Subversion, since that can be automated.
I think we would need much more discipline in our commit logs for that.
>Also, I think it probably is a good idea to choose a "standard" format
>for RELEASE-NOTES.txt across the various projects which depend on
>parent-v3 which should include the date and Subversion revision number
>of each released version.
On the SP side, I don't bother to even generate them. I include a file
with links to the page that allows people to generate them for specific
versions and leave it at that. It's one less thing to maintain.
Those are my views.
-- Scott
More information about the dev
mailing list