> To do so it uses the jira rest api (which is nice btw). This is something I
> would like feedback on.
Bleck - tough call.
> We have a couple of options here on what to do with respect to jira.
>
> 1. don't do any checks against jira, and leave that a manual process
In my experience going through the Jira list is educational; for two reasons:
- as often I find items that are marked "resolved" but not yet closed as they
are waiting confirmation.
- often issues are fixed (usually due to issues being duplicated etc…)
This is also our "last chance" to see what is going on before the issues are
punted over to the next release.
> 2. halt the build if the release is not released in jira or there are
> unresolved issues, making releasing on a jira manually a precursor to running
> the script
>
>
> 3. mark the release as released in jira, and push back any unresolved issues
> to the next version
>
>
I would go with this option (despite the temptation to halt the build for
manual review).
Reason is:
a) we are shooting for a two hour release window
b) we can update the release notes in Jira after the fact; and the page will
update
> More options welcome.
>
>
Can we promote any "resolved' issues to "closed" if they have now been included
in a release?
Jody
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel