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
The second thing I would like to discuss is how we handle the README.
Currently when we release we update the README on the main branch (and not
the tag). I would kind of like to avoid committing anything to the main
branch in an automated process. For example what happens if we run the
You were very fast Justin :)
Don't have time right now to take a deep look at the scripts but I will do
during the we as a personal interest.
Thanks for achieving this.
About JIRA, I also think option 3 is the best one.
Do you still need help to do something in order to close up this task?
On Wed, May 16, 2012 at 1:48 AM, Jody Garnett jody.garn...@gmail.comwrote:
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
On Wed, May 16, 2012 at 1:53 AM, Andrea Aime
andrea.a...@geo-solutions.itwrote:
On Wed, May 16, 2012 at 7:55 AM, Justin Deoliveira jdeol...@opengeo.org
wrote:
The end result is all the artifacts wind up in a single directory
matching
the release name. For example:
On Wed, May 16, 2012 at 1:54 AM, Jody Garnett jody.garn...@gmail.comwrote:
The second thing I would like to discuss is how we handle the README.
Currently when we release we update the README on the main branch (and not
the tag). I would kind of like to avoid committing anything to the main
Hi all,
I have been working on the scripts to automate our release process. Here is
where things are at.
First, if you want to take a look at the scripts they are in my github repo
in a branch called build_scripts:
https://github.com/jdeolive/geoserver/tree/build_scripts/build
Here is how
