+1 and yeah good idea. You would need to release in Jira and feed that number
into the script as well (for the release notes).
--
Jody Garnett
On Saturday, 1 October 2011 at 2:50 AM, Justin Deoliveira wrote:
> Yeah I think a new hudson job on the build server could do all of this and
> automate pretty everything minus the announcements. Basically the input would
> simply be a release number and a revision. The job would tag, build, update
> version numbers, etc... It is definitely a fair bit of scripting work but
> certainly doable.
>
> Which brings me to a related point, i would like to commit all the hudson
> scripts into svn... there is a lot of logic there and currently it is just
> sittin gon the build server unversioned.
>
> On Fri, Sep 30, 2011 at 6:47 AM, Jody Garnett <[email protected]
> (mailto:[email protected])> wrote:
> > > The current situation, with the cite tests running every night, is
> > > certainly better
> > > than it was once, but there is still a lot of work to do, and that work
> > > has to
> > > be done by someone that has all the keys to the project administration
> > > areas.
> > >
> > >
> > >
> > >
> >
> >
> > In a perfect world the maven release target would work and take care of
> > tagging etc. We could then place that in hudson and ask someone to poke the
> > button (and make the JIRA release notes).
> > > Sometimes I'd like to delegate the release to some of my colleages at
> > > work that might have a few spare hours, but they don't even have commit
> > > access so that is not feasible.
> > >
> > See above; as long as hudson has commit access it would work. But they
> > would need to sign up to seven Xircles of haus in order to kick out the
> > Jira release notes.
> > > Any suggestions on what we could do to improve the release process?
> > >
> > >
> > >
> >
> >
> > I am a big fan of trying the collaborate; and have a standing offer open to
> > release GeoTools if someone needs to make a GeoServer or uDig release.
> >
> > That does not however make good use of your colleagues. In a sense when the
> > release process was in terrible shape it was easier to make use of
> > volunteers for testing and QA.
> > > The ideal-ideal situation would be something like a customized hudson
> > > build
> > > that given the release notes and the branch name does it all, making the
> > > packages
> > > available for upload to sourceforge and the like.
> > > But any way to further shrink the release times would be welcomed
> > >
> > >
> > >
> > >
> >
> >
> > We could write a shell script for some stages of the release process (the
> > staging of files to be zipped up and uploaded to source forge for example).
> > We have done something similar for uDig now and it makes an amazing
> > difference in how easy it is to make a release.
> >
> > If we were really worried about cross platform we could make it an ant
> > script.
> >
> > Jody
> > ------------------------------------------------------------------------------
> > All of the data generated in your IT infrastructure is seriously valuable.
> > Why? It contains a definitive record of application performance, security
> > threats, fraudulent activity, and more. Splunk takes this data and makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy2
> > _______________________________________________
> > Geotools-devel mailing list
> > [email protected]
> > (mailto:[email protected])
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >
>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
