[Geoserver-devel] Simplifying and speeding up the release process

GeoServer GeoServer Developer
1

Hi,
I'd like to discuss with everybody the current situation about releases.
Or should I say, about the lack of them :-p

As far as I can see it, the lack of releases in GeoServer is due to the
mix of two factors:
- people involved in the project are damn busy, so there is general
  lack of time
- the release process takes too much time, has been designed in
  times when people could dedicate one day to it and now that amount
  of time is simply not there

At the same time the testing level of geoserver increased steadily
and thanks to Justin's effort we have CITE tests running every
night checking the GeoServer code base.
I think I'm not the only one that routinely uses only nightly builds
for production deploys: the automated testing level is so good that a nightly
build generally has nothing to envy to a released version, on
the contrary, especially on the stable branch is often much
better (the 2.0.x nightly has something like 58 bug fixes compared
to 2.0.2, see [1])

If you look at the release process, QA wise all we add is some interactive
testing.

I would like to see a new release process in place where all that
needs to be done in order to cut a release is to grab the artifacts
from a nightly build that passed all the unit tests and all
of the cite tests and go from there:
- do the interactive testing
- build the installer
- push the artifacts on sourceforge
- announce the release (on less sites than we do today).

In this ideal situation it would take only a few hours to release
both geotools and geoserver (I'm thinking something
in the ballpark of 2-4 hours).

In order to get there we need at the very least to:
- include the svn revision number in the built artifacts
  (so that we know what to tag)
- have the cite tests pull a geoserver out of the nightly
  repo instead of using a potentially different thing
  built with some changes that were not in the nightly

The first item could be accomplished by using this
maven plugin:
http://maven-svn-revision-number-plugin.googlecode.com/svn/site/examples/resource_filtering.html
We could have the revision added in each jar META-INF
folder, as well as put it in the name of the artifacts built.
Also the nightly build would have to run all the tests
fully (extensive, whatnot).

The second might require some changes in the way the
cite tests are run, and would also demand that the
cite results declare something like "success with
nightly build from revision xyz".

It would still not be the mythical "one button push
release" but it might get us closer enough to restore
monthly or bi-monthly releases.

Opinions? Suggestions on work items that we're missing
to have a good and mostly automated release process?

Cheers
Andrea

[1]: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+fixVersion+%3D+"2.0.3"+AND+status+in+(Resolved%2C+Closed)

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

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

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

2

That sounds sensible to me; the only glitch I see is perhaps due to a separate goal. I would like to see geotools released occasionally; and we have had the policy of only releasing geotools when geoserver passes cite tests. The only time for that to happen has been when geoserver has been released ...

It sounds like we could do that more often after Justin's QA work.

So if we released geotools; deployed; and cut trunk over to the correct version of GeoTools for a day or so we could still get a nightly built with non snapshot copy of geotools? And then proceed with the rest of your plan.

So what does that look like...
1. call a code freeze
2. release geotools and switch geoserver over to it
3. force a nightly release and run of cite tests (or wait till the next day)
4. tag geoserver and release (installers etc...)
5. call off the code freeze

There is a chance we would stuff something up in the tag/release process but I get your point; the extra effort to run cite tests is punishing.

Cheers,
Jody

On 07/11/2010, at 6:34 AM, Andrea Aime wrote:

Hi,
I'd like to discuss with everybody the current situation about releases.
Or should I say, about the lack of them :-p

As far as I can see it, the lack of releases in GeoServer is due to the
mix of two factors:
- people involved in the project are damn busy, so there is general
lack of time
- the release process takes too much time, has been designed in
times when people could dedicate one day to it and now that amount
of time is simply not there

At the same time the testing level of geoserver increased steadily
and thanks to Justin's effort we have CITE tests running every
night checking the GeoServer code base.
I think I'm not the only one that routinely uses only nightly builds
for production deploys: the automated testing level is so good that a nightly
build generally has nothing to envy to a released version, on
the contrary, especially on the stable branch is often much
better (the 2.0.x nightly has something like 58 bug fixes compared
to 2.0.2, see [1])

If you look at the release process, QA wise all we add is some interactive
testing.

I would like to see a new release process in place where all that
needs to be done in order to cut a release is to grab the artifacts
from a nightly build that passed all the unit tests and all
of the cite tests and go from there:
- do the interactive testing
- build the installer
- push the artifacts on sourceforge
- announce the release (on less sites than we do today).

In this ideal situation it would take only a few hours to release
both geotools and geoserver (I'm thinking something
in the ballpark of 2-4 hours).

In order to get there we need at the very least to:
- include the svn revision number in the built artifacts
(so that we know what to tag)
- have the cite tests pull a geoserver out of the nightly
repo instead of using a potentially different thing
built with some changes that were not in the nightly

The first item could be accomplished by using this
maven plugin:
http://maven-svn-revision-number-plugin.googlecode.com/svn/site/examples/resource_filtering.html
We could have the revision added in each jar META-INF
folder, as well as put it in the name of the artifacts built.
Also the nightly build would have to run all the tests
fully (extensive, whatnot).

The second might require some changes in the way the
cite tests are run, and would also demand that the
cite results declare something like "success with
nightly build from revision xyz".

It would still not be the mythical "one button push
release" but it might get us closer enough to restore
monthly or bi-monthly releases.

Opinions? Suggestions on work items that we're missing
to have a good and mostly automated release process?

Cheers
Andrea

[1]: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+fixVersion+%3D+"2.0.3"+AND+status+in+(Resolved%2C+Closed)

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

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

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

On Sat, Nov 6, 2010 at 11:34 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

That sounds sensible to me; the only glitch I see is perhaps due to a separate goal. I would like to see geotools released occasionally; and we have had the policy of only releasing geotools when geoserver passes cite tests. The only time for that to happen has been when geoserver has been released ...

It sounds like we could do that more often after Justin's QA work.

In fact there is nothing stopping you from releasing geotools wherever you want.

So if we released geotools; deployed; and cut trunk over to the correct version of GeoTools for a day or so we could still get a nightly built with non snapshot copy of geotools? And then proceed with the rest of your plan.

Right, we cannot exactly take the artifacts built during the night because they
contain SNAPSHOT in the version number.
Wondering if it would be possible to make a Hudson "release" build that takes
the svn revision of geotools, the target revision, and automates it all
(tag, rename, commit, package, deploy).
And something similar for GeoServer as well.

So what does that look like...
1. call a code freeze

I would not even want to go there. If we know that revision N of GeoTools passed
all the tests and was good for GeoServer CITE tests we just have to tag
it and release it.
Calling out before the release should still be done to ensure there is no big
work in progress, but on a quiet branch such as 2.6.x and 2.0.x I would not
see the problem in taking a arbitrary revision number that passed all the
tests and calling it the release.

2. release geotools and switch geoserver over to it
3. force a nightly release and run of cite tests (or wait till the next day)
4. tag geoserver and release (installers etc...)
5. call off the code freeze

I think this would not work. We cannot have an extensive freeze, but I know
I may have 2 spare hours one day to make a release and then be chock full
of other work for two weeks.
I'd like a release process that can work within these short and unpredictable
windows of spare time. As we have seen in the last months asking for a more
controlled and predictable release management simply does not work,
we don't have the time for it.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

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

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

4

This is sure to be an interesting thread. Here are some of my thoughts.

I totally agree that we need a much more agile and lightweight release process. And I think much could be done in support of this starting with the build server. As Andrea suggests we should be producing artifacts that contain svn revision information. This has been something on my todo list for some time regardless.

My only worry about such a release process would be that currently our commit policies allow us to commit changes quite liberally to the stable branch. If we are going to be releasing more often I would like to see that policy more strict and kept to bug fixes only. Currently we do have a very long release cycle but at least it gives developers and users who try nightly builds to flush out regressions that are introduced. However on the other hand a lighter weight process allows us to push out release much more quickly, so if we do ship a regression at least it will be easy to release a new release

At the end of the day GeoServer is tied to Geotools. And currently the restriction of having to put a geotools release for every geoserver really ties our hands. If releasing geotools takes a day there is only so much we can do. We could consider dropping the requirement of having to ship with an official geotools release. However I sympathize with Jody in that this would mean less (if any) geotools releases.

In the end I think the best way forward would be to try to also make the geotools release process better as well. If releasing geotools were easier we could drop the requirement of having an official geotools release, and still produce regular geotools releases.

I think much could be done on the build server to make the release process for both projects nicer. Basically a new job that you fire off, enter in svn revision information, tag name, etc… and all the release artifacts get spit out automagically. That coupled with adding svn revision to nightly builds I think will go a long way.

2c.

-Justin

On Sun, Nov 7, 2010 at 1:48 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sat, Nov 6, 2010 at 11:34 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

That sounds sensible to me; the only glitch I see is perhaps due to a separate goal. I would like to see geotools released occasionally; and we have had the policy of only releasing geotools when geoserver passes cite tests. The only time for that to happen has been when geoserver has been released …

It sounds like we could do that more often after Justin’s QA work.

In fact there is nothing stopping you from releasing geotools wherever you want.

So if we released geotools; deployed; and cut trunk over to the correct version of GeoTools for a day or so we could still get a nightly built with non snapshot copy of geotools? And then proceed with the rest of your plan.

Right, we cannot exactly take the artifacts built during the night because they
contain SNAPSHOT in the version number.
Wondering if it would be possible to make a Hudson “release” build that takes
the svn revision of geotools, the target revision, and automates it all
(tag, rename, commit, package, deploy).
And something similar for GeoServer as well.

So what does that look like…

  1. call a code freeze

I would not even want to go there. If we know that revision N of GeoTools passed
all the tests and was good for GeoServer CITE tests we just have to tag
it and release it.
Calling out before the release should still be done to ensure there is no big
work in progress, but on a quiet branch such as 2.6.x and 2.0.x I would not
see the problem in taking a arbitrary revision number that passed all the
tests and calling it the release.

  1. release geotools and switch geoserver over to it
  2. force a nightly release and run of cite tests (or wait till the next day)
  3. tag geoserver and release (installers etc…)
  4. call off the code freeze

I think this would not work. We cannot have an extensive freeze, but I know
I may have 2 spare hours one day to make a release and then be chock full
of other work for two weeks.
I’d like a release process that can work within these short and unpredictable
windows of spare time. As we have seen in the last months asking for a more
controlled and predictable release management simply does not work,
we don’t have the time for it.

Cheers
Andrea

Ing. Andrea Aime
Senior Software Engineer

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

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

The Next 800 Companies to Lead America’s Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book “Blueprint to a
Billion” shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

This is a good idea IMHO - particularly if the process of tagging and
assigning release identifiers can be automated - automation requires
clarity of the process, which is a good thing too :slight_smile:

Andrea's experience about whats actually most reliable is really
important to learn from.

Two suggestions/comments:

1) You might use something like a doodle poll to set a release date
(say with a two week window?) - then anyone who some stuff in the
pipeline who wants a couple of days grace can vote - if you get no
negative votes on the doodle, schedule an automated release on the
earliest date

2) Having to configure specially for CITE tests is a nasty nasty thing
- sure there is data involved we dont want to distribute, but its an
anathema for interoperability to use magic to pass conformance tests.
Automating running them sure is a huge improvement though. I wonder
how much app-schema support would buy us being able to pass CITE tests
out-of-the-box? Is there a jira task or wiki page which specifies all
the impacts of the CITE specific config so we could review each of
these and plan a cleaner solution?

Rob

On Tue, Nov 9, 2010 at 2:10 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

This is sure to be an interesting thread. Here are some of my thoughts.
I totally agree that we need a much more agile and lightweight release
process. And I think much could be done in support of this starting with the
build server. As Andrea suggests we should be producing artifacts that
contain svn revision information. This has been something on my todo list
for some time regardless.
My only worry about such a release process would be that currently our
commit policies allow us to commit changes quite liberally to the stable
branch. If we are going to be releasing more often I would like to see that
policy more strict and kept to bug fixes only. Currently we do have a very
long release cycle but at least it gives developers and users who try
nightly builds to flush out regressions that are introduced. However on the
other hand a lighter weight process allows us to push out release much more
quickly, so if we do ship a regression at least it will be easy to release a
new release
At the end of the day GeoServer is tied to Geotools. And currently the
restriction of having to put a geotools release for every geoserver really
ties our hands. If releasing geotools takes a day there is only so much we
can do. We could consider dropping the requirement of having to ship with an
official geotools release. However I sympathize with Jody in that this would
mean less (if any) geotools releases.
In the end I think the best way forward would be to try to also make the
geotools release process better as well. If releasing geotools were easier
we could drop the requirement of having an official geotools release, and
still produce regular geotools releases.
I think much could be done on the build server to make the release process
for both projects nicer. Basically a new job that you fire off, enter in svn
revision information, tag name, etc... and all the release artifacts get
spit out automagically. That coupled with adding svn revision to nightly
builds I think will go a long way.
2c.
-Justin
On Sun, Nov 7, 2010 at 1:48 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Sat, Nov 6, 2010 at 11:34 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:
> That sounds sensible to me; the only glitch I see is perhaps due to a
> separate goal. I would like to see geotools released occasionally; and we
> have had the policy of only releasing geotools when geoserver passes cite
> tests. The only time for that to happen has been when geoserver has been
> released ...
>
> It sounds like we could do that more often after Justin's QA work.

In fact there is nothing stopping you from releasing geotools wherever you
want.

> So if we released geotools; deployed; and cut trunk over to the correct
> version of GeoTools for a day or so we could still get a nightly built with
> non snapshot copy of geotools? And then proceed with the rest of your plan.

Right, we cannot exactly take the artifacts built during the night because
they
contain SNAPSHOT in the version number.
Wondering if it would be possible to make a Hudson "release" build that
takes
the svn revision of geotools, the target revision, and automates it all
(tag, rename, commit, package, deploy).
And something similar for GeoServer as well.

>
> So what does that look like...
> 1. call a code freeze

I would not even want to go there. If we know that revision N of GeoTools
passed
all the tests and was good for GeoServer CITE tests we just have to tag
it and release it.
Calling out before the release should still be done to ensure there is no
big
work in progress, but on a quiet branch such as 2.6.x and 2.0.x I would
not
see the problem in taking a arbitrary revision number that passed all the
tests and calling it the release.

> 2. release geotools and switch geoserver over to it
> 3. force a nightly release and run of cite tests (or wait till the next
> day)
> 4. tag geoserver and release (installers etc...)
> 5. call off the code freeze

I think this would not work. We cannot have an extensive freeze, but I
know
I may have 2 spare hours one day to make a release and then be chock full
of other work for two weeks.
I'd like a release process that can work within these short and
unpredictable
windows of spare time. As we have seen in the last months asking for a
more
controlled and predictable release management simply does not work,
we don't have the time for it.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

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

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

On Tue, Nov 9, 2010 at 12:43 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

This is a good idea IMHO - particularly if the process of tagging and
assigning release identifiers can be automated - automation requires
clarity of the process, which is a good thing too :slight_smile:

Andrea's experience about whats actually most reliable is really
important to learn from.

Two suggestions/comments:

1) You might use something like a doodle poll to set a release date
(say with a two week window?) - then anyone who some stuff in the
pipeline who wants a couple of days grace can vote - if you get no
negative votes on the doodle, schedule an automated release on the
earliest date

This still assumes you can plan ahead a release by two weeks.
I'm not normally in such conditions, I can have the occasional slow day,
or the boring weekend, but I cannot foresee when that will happen.
What I'd like to see is the possibility to cut a release with minimal
warning instead.
Something like: "yesterday's build passed all the tests and it appears to
be good for a release, did anybody had a work in progress that would make
it non releasable or can I go and package it up"?

My observation is that, especially on the stable branch, there are
many subsequent
days when not much is happening, and that are far away enough from the last
large change, and the builds of those days can be considered for packaging
and release.
The idea is not to plan for a release, but to realize the material for one is
already there and use it (as I said, that might work well only on a
stable series).

2) Having to configure specially for CITE tests is a nasty nasty thing
- sure there is data involved we dont want to distribute, but its an
anathema for interoperability to use magic to pass conformance tests.
Automating running them sure is a huge improvement though. I wonder
how much app-schema support would buy us being able to pass CITE tests
out-of-the-box? Is there a jira task or wiki page which specifies all
the impacts of the CITE specific config so we could review each of
these and plan a cleaner solution?

I don't think there is such a thing, but someone just needs to pick a IDE
and see where the cite hacks flag is used.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

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

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

7

This still assumes you can plan ahead a release by two weeks.
I'm not normally in such conditions, I can have the occasional slow day,
or the boring weekend, but I cannot foresee when that will happen.
What I'd like to see is the possibility to cut a release with minimal
warning instead.
Something like: "yesterday's build passed all the tests and it appears to
be good for a release, did anybody had a work in progress that would make
it non releasable or can I go and package it up"?

Fair enough - perhaps we can invert control - would it be useful if
someone is landing something allow them to put in a short lived
request for delaying a release ?

8

On Wed, Nov 10, 2010 at 6:01 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

This still assumes you can plan ahead a release by two weeks.
I'm not normally in such conditions, I can have the occasional slow day,
or the boring weekend, but I cannot foresee when that will happen.
What I'd like to see is the possibility to cut a release with minimal
warning instead.
Something like: "yesterday's build passed all the tests and it appears to
be good for a release, did anybody had a work in progress that would make
it non releasable or can I go and package it up"?

Fair enough - perhaps we can invert control - would it be useful if
someone is landing something allow them to put in a short lived
request for delaying a release ?

If anyone is landing big changes she should be warning the mailing
list anyways, no?

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

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

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

9

At the end of the day GeoServer is tied to Geotools. And currently the
restriction of having to put a geotools release for every geoserver really
ties our hands. If releasing geotools takes a day there is only so much we
can do. We could consider dropping the requirement of having to ship with an
official geotools release. However I sympathize with Jody in that this would
mean less (if any) geotools releases.

I have always volunteer to do the 1/2 day work needed for a geotools
release. The offer still stands; it is just nobody has asked.

I also got a bit fed up when I was asked not to release GeoTools 2.7;
and have been stuck in limbo waiting for a road map that never came.

In the end I think the best way forward would be to try to also make the
geotools release process better as well. If releasing geotools were easier
we could drop the requirement of having an official geotools release, and
still produce regular geotools releases.

So far the only trouble is waiting for cite tests; I think with your
recent work I could skip that wait and be much happier for it.

The only other thing to skip would be unpacking the resulting geotools
package and making sure it builds from source; that would save 15 mins
or so.

I think much could be done on the build server to make the release process
for both projects nicer. Basically a new job that you fire off, enter in svn
revision information, tag name, etc... and all the release artifacts get
spit out automagically. That coupled with adding svn revision to nightly
builds I think will go a long way.

So would I tag geotools; update the hudson job description to point to
the correct tag; and the hit go?
That could work.

2c.

2c is not very much these days; Australia does not even have pennies.
I think I can do 5c though.

Jody

On Sun, Nov 7, 2010 at 1:48 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Sat, Nov 6, 2010 at 11:34 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:
> That sounds sensible to me; the only glitch I see is perhaps due to a
> separate goal. I would like to see geotools released occasionally; and we
> have had the policy of only releasing geotools when geoserver passes cite
> tests. The only time for that to happen has been when geoserver has been
> released ...
>
> It sounds like we could do that more often after Justin's QA work.

In fact there is nothing stopping you from releasing geotools wherever you
want.

> So if we released geotools; deployed; and cut trunk over to the correct
> version of GeoTools for a day or so we could still get a nightly built with
> non snapshot copy of geotools? And then proceed with the rest of your plan.

Right, we cannot exactly take the artifacts built during the night because
they
contain SNAPSHOT in the version number.
Wondering if it would be possible to make a Hudson "release" build that
takes
the svn revision of geotools, the target revision, and automates it all
(tag, rename, commit, package, deploy).
And something similar for GeoServer as well.

>
> So what does that look like...
> 1. call a code freeze

I would not even want to go there. If we know that revision N of GeoTools
passed
all the tests and was good for GeoServer CITE tests we just have to tag
it and release it.
Calling out before the release should still be done to ensure there is no
big
work in progress, but on a quiet branch such as 2.6.x and 2.0.x I would
not
see the problem in taking a arbitrary revision number that passed all the
tests and calling it the release.

> 2. release geotools and switch geoserver over to it
> 3. force a nightly release and run of cite tests (or wait till the next
> day)
> 4. tag geoserver and release (installers etc...)
> 5. call off the code freeze

I think this would not work. We cannot have an extensive freeze, but I
know
I may have 2 spare hours one day to make a release and then be chock full
of other work for two weeks.
I'd like a release process that can work within these short and
unpredictable
windows of spare time. As we have seen in the last months asking for a
more
controlled and predictable release management simply does not work,
we don't have the time for it.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

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

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.