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 <[email protected]>wrote:
> On Sat, Nov 6, 2010 at 11:34 PM, Jody Garnett <[email protected]>
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
