OSGeo.org › OSGeo Software and Data Projects › GeoTools, the java GIS toolkit › geotools-devel

automated release scripts

Classic

List

Threaded

7 messages Options

Justin Deoliveira

automated release scripts

Hi all,

Many of you may have followed the discussion a ways back about automating the GeoServer release process. That is going well and we know have a set of release scripts that mostly automate GeoServer releases, along with soem hudson jobs to invoke them.

I would like to do the same with GeoTools. Here is the first cut of the scripts.

https://github.com/jdeolive/geotools/commit/4422cb99e5ceea9b5845e0359fcc279e5163cc1d

With that the plan is to throw together jobs in hudson similar to the following:

Builds the main release artifacts:

http://hudson.opengeo.org/hudson/job/geoserver-release/

Performs the release in JIRA:

http://hudson.opengeo.org/hudson/job/geoserver-release-jira/

Does the final pubishing, uploading to sourceforge, maven deploy, etc...

http://hudson.opengeo.org/hudson/job/geoserver-release-publish/

Thoughts? Opinions? Objections?

For some more background about how the geoserver stuff is invoked, see this document i whipped up.

https://github.com/jdeolive/geoserver/blob/build_scripts/doc/en/developer/source/release-guide/automated.rst

Basically the process for GeoTools would be similar, and a lot simpler.

-Justin

--
Justin Deoliveira

OpenGeo - http://opengeo.org

Enterprise support for open source geospatial.

------------------------------------------------------------------------------
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/
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

jody.garnett

Re: automated release scripts

With that the plan is to throw together jobs in hudson similar to the following:

Builds the main release artifacts:
http://hudson.opengeo.org/hudson/job/geoserver-release/

We got a few 'rename' steps to perform both before and after branch:

0) modify build/rename.xml with the new version numbers; a bit tricky

1) ant -f build/rename.xml doc - so the docs come out referring to the stable release

2) commit onto trunk

2) tag

3) ant -f build/rename code

4) ant -f build/rename readme

5) commit onto tag

(Reminds me to update the docs to say 8.0-RC1 now)

Cheers,

Jody

Justin Deoliveira

Re: automated release scripts

Yeah, if you look at the patch it actually modifies the rename script so that on the main branch it is never modified. Basically adding a @VERSION@ placeholder.

Anyways, the scripts take this into account, i have just never ran them through a full trial to test the commit back but its the same pattern as GeoServer and I just cribbed the scripts from there and stripped them down.

On Mon, May 28, 2012 at 10:44 PM, Jody Garnett <[hidden email]> wrote:

With that the plan is to throw together jobs in hudson similar to the following:

Builds the main release artifacts:
http://hudson.opengeo.org/hudson/job/geoserver-release/

We got a few 'rename' steps to perform both before and after branch:

0) modify build/rename.xml with the new version numbers; a bit tricky
1) ant -f build/rename.xml doc - so the docs come out referring to the stable release

2) commit onto trunk
2) tag
3) ant -f build/rename code
4) ant -f build/rename readme
5) commit onto tag

(Reminds me to update the docs to say 8.0-RC1 now)

Cheers,
Jody

--
Justin Deoliveira

OpenGeo - http://opengeo.org

Enterprise support for open source geospatial.

jody.garnett

Re: automated release scripts

Yeah, if you look at the patch it actually modifies the rename script so that on the main branch it is never modified. Basically adding a @VERSION@ placeholder.

Understood; we also need to update a few doc references (on the main branch) in anticipation of the release being a success.

Anyways, the scripts take this into account, i have just never ran them through a full trial to test the commit back but its the same pattern as GeoServer and I just cribbed the scripts from there and stripped them down.

So the example pom.xml files in docs/user/tutorials need to reflect the release version number; and the build/pom.xml and common.py also have a reference.

Jody

Justin Deoliveira

Re: automated release scripts

Just committed the release scripts.

On Tue, May 29, 2012 at 9:09 PM, Jody Garnett <[hidden email]> wrote:

Yeah, if you look at the patch it actually modifies the rename script so that on the main branch it is never modified. Basically adding a @VERSION@ placeholder.

Understood; we also need to update a few doc references (on the main branch) in anticipation of the release being a success.

Anyways, the scripts take this into account, i have just never ran them through a full trial to test the commit back but its the same pattern as GeoServer and I just cribbed the scripts from there and stripped them down.

So the example pom.xml files in docs/user/tutorials need to reflect the release version number; and the build/pom.xml and common.py also have a reference.

Hmm... ok. I thought this was all handled by rename.xml? If not that is fine, just need to know what files to change the version in. And on the main branches replace any version numbers that are there with the same @VERSION@ placeholder. Then we just need to update the release script to do the place with sed.

Jody

--
Justin Deoliveira

OpenGeo - http://opengeo.org

Enterprise support for open source geospatial.

Alessio Fabiani-2

Re: automated release scripts

Hello guys,

I'm going to do geotools 2.7.5 release at most tomorrow ... I would like to know the status of automated scripts, if everything has been committed and if the hudson jobs are working.

Is there something pending to do yet?

Regards,

Alessio.

-------------------------------------------------------

Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
http://www.linkedin.com/in/alessiofabiani

https://twitter.com/alfa7961
http://twitter.com/geosolutions_it
-------------------------------------------------------

On Wed, May 30, 2012 at 5:47 AM, Justin Deoliveira <[hidden email]> wrote:

Just committed the release scripts.

On Tue, May 29, 2012 at 9:09 PM, Jody Garnett <[hidden email]> wrote:

Yeah, if you look at the patch it actually modifies the rename script so that on the main branch it is never modified. Basically adding a @VERSION@ placeholder.

Understood; we also need to update a few doc references (on the main branch) in anticipation of the release being a success.

Anyways, the scripts take this into account, i have just never ran them through a full trial to test the commit back but its the same pattern as GeoServer and I just cribbed the scripts from there and stripped them down.

So the example pom.xml files in docs/user/tutorials need to reflect the release version number; and the build/pom.xml and common.py also have a reference.

Hmm... ok. I thought this was all handled by rename.xml? If not that is fine, just need to know what files to change the version in. And on the main branches replace any version numbers that are there with the same @VERSION@ placeholder. Then we just need to update the release script to do the place with sed.

Jody

--
Justin Deoliveira
OpenGeo - http://opengeo.org

Enterprise support for open source geospatial.

------------------------------------------------------------------------------
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/
_______________________________________________
GeoTools-Devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

jody.garnett

Re: automated release scripts

In reply to this post by Justin Deoliveira

So the example pom.xml files in docs/user/tutorials need to reflect the release version number; and the build/pom.xml and common.py also have a reference.

Hmm... ok. I thought this was all handled by rename.xml?

It is supposed to be; but it only works when it can catch 8.0-M4 --> 8.0-RC1. If we missing committing the changed pom.xml files on trunk; then next release the matches won't be found.

Note this is only a trouble in tutorial examples; where we are asking them to refer to the most recent release (rather than a snapshot).

Jody