I think the one thing why I would go for branching off the 2.1-RC1
revision is the geotools version. So that only trunk keeps on gt-trunk
and the branch on gt-2.7-beta1.
Then I can backport the front page capabilities stuff as it's low risk,
but looks cleaner to branch as of the tagged release version?
Cheers,
Gabriel
On Mon, 2011-01-17 at 08:34 -0700, Justin Deoliveira wrote:
I have not created the 2.1.x branch, i was waiting for some more
general consensus.
If people can agree it should be created now i can create the branch.
Two options:
(a) grab trunk as of now and branch it
(b) grab trunk as of the revision for 2.1-RC1 and create the branch
from it
It sounds like Chris would prefer (b). Last week we more or less
agreed that "stable development" meant bug fixes and modest features
generally considered low risk. This would tend to jive with what we
have done in the past as well on the stable branch although at times
we have been pretty liberal with the term stable development.
We also tend to go through a number of release candidates before the
official .0 release. Not sure we have every done a single RC and then
called it good if no issues come up. Not against it by any means, it
just never really turned out that way.
Anyways, like I said something I would like others to comment on. I
would be good with branching 2.1.x from current trunk since nothing to
core and considered risk has taken place. And then just keep with our
definition of stable for what gets backported to 2.1.x branch.
On Sun, Jan 16, 2011 at 10:04 PM, Gabriel Roldán <groldan@anonymised.com>
wrote:
Good question, I'm not sure though.
I checked if the pom version was updated before committed and
since it
was not I just assumed it was ok. Let's see what Justin says.
Gabriel
On Sun, 2011-01-16 at 22:12 -0500, Chris Holmes wrote:
> Is trunk actually a real trunk yet? Looking at svn it looks
like
> there's a RC1 tag, but not a 2.1.x branch yet. I think this
is a
> great patch for trunk/2.2.x, to be backported for 2.1.0, but
I was
> hoping RC1 would be a real Release Candidate - become 2.1.0
if there
> were no major bugs.
>
> On Sun, Jan 16, 2011 at 5:32 PM, Gabriel Roldán
<groldan@anonymised.com>
> wrote:
> On Sun, 2011-01-16 at 10:53 +0100, Andrea Aime
wrote:
> > On Sun, Jan 16, 2011 at 8:56 AM, Gabriel Roldán
> <groldan@anonymised.com> wrote:
> > > Hi all,
> > >
> > > As per
http://jira.codehaus.org/browse/GEOS-4162, I worked
> out a patch
> > > that incorporates an extension point for
contributing to
> the
> > > getcapabilities links in the home page.
> > > You can see the diff at
> > >
>
<https://github.com/groldan/geoserver_trunk/compare/master...getcaps_ui_integration>
> > >
> > > There's a default implementation of this
extension point
> that grabs the
> > > available ServiceInfo objects and creates the
standard ows
> getcaps links
> > > as GeoServerHomePage used to do, and an
implementation in
> the GWC module
> > > that contributes the links for the WMS-C, WMTS
and TMS
> services.
> > >
> > > If there's no oppositions I'd like to merge this
into
> trunk by this
> > > week.
> >
> > Sound good to me. Just a question, why passing
around the
> GeoServerApplication
> > class?
> > That is made available as a singleton to all pages
> > by using GeoServerApplication.get().
> > Using a model indirection seems un-necessary extra
code to
> me.
>
>
> Good catch, I removed it as argument and accessed as
> singleton.
> Committed now. Thanks for the feedback.
>
> Gabriel.
> >
> > Cheers
> > Andrea
> >
>
> --
> Gabriel Roldan
> groldan@anonymised.com
> Expert service straight from the developers
>
>
>
------------------------------------------------------------------------------
>
>
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid
them.
> Understand
> malware threats, the impact they can have on your
business,
> and how you
> can protect your company and customers by using code
signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them.
Understand
malware threats, the impact they can have on your business,
and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
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.
--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers
