> > 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 -
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.
-
Just committed the release scripts.
On Tue, May 29, 2012 at 9:09 PM, Jody Garnett 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
> 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.
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 patt
> 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 th
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 GeoTo
