[Geoserver-devel] 1.3.x, 1.4.x, which should be trunk?

Hi all,

With 1.3.0 out, and development ramping up on 1.4.x, i think we need to decide how things will be organized in the repository in terms of branches vs trunk.

Right now things are laid out as follows:

1.3.x = trunk
1.4.x = branch
complex-features = branch of 1.4.x

So I guess the big question is should 1.4.x be made the new trunk and 1.3.x put out on a maintenance branch?

My recommendation would be as follows (and please feel free to disagree)

1.4.x = trunk
1.3.x = branch
complex-features = branch

Since 1.4.x is really just 1.3.x. + spring container + code broken up into modules it is still quite "stable". It passes all unit tests and ogc cite tests. So having it as trunk isn't really all that different then the way things are today. The only big thing is the new build system which a few people have successfully been able to use.

Since the complex stuff is going to be pretty shaky for a couple of weeks to come, it needs to stay out on a branch for a little while yet before getting merged back onto 1.4.x / trunk / whatever we decide.

So this email is just really to start up conversation about what people think. And possibly come to come to a resolution about it.

-Justin

I'm not sure my opinion carries a lot of weight, but what you propose is pretty much what I've come to regard as standard operating procedure. I'm kind-of surprised you guys didn't put 1.3.0 (--> 1.3.x) onto a branch earlier and then just do the 1.4.x refactor right on the trunk.

I think both makes sense and is a good idea.

Then again, SOP hasn't ever created anything halfway as cool as geoserver before!

--saul

Justin Deoliveira wrote:

Hi all,

With 1.3.0 out, and development ramping up on 1.4.x, i think we need to decide how things will be organized in the repository in terms of branches vs trunk.

Right now things are laid out as follows:

1.3.x = trunk
1.4.x = branch
complex-features = branch of 1.4.x

So I guess the big question is should 1.4.x be made the new trunk and 1.3.x put out on a maintenance branch?

My recommendation would be as follows (and please feel free to disagree)

1.4.x = trunk
1.3.x = branch
complex-features = branch

Since 1.4.x is really just 1.3.x. + spring container + code broken up into modules it is still quite "stable". It passes all unit tests and ogc cite tests. So having it as trunk isn't really all that different then the way things are today. The only big thing is the new build system which a few people have successfully been able to use.

Since the complex stuff is going to be pretty shaky for a couple of weeks to come, it needs to stay out on a branch for a little while yet before getting merged back onto 1.4.x / trunk / whatever we decide.

So this email is just really to start up conversation about what people think. And possibly come to come to a resolution about it.

-Justin

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Good, always good to know i am not totally out to lunch :). And your opinion definitley carries weight here Saul.

-Justin

Saul Farber wrote:

I'm not sure my opinion carries a lot of weight, but what you propose is pretty much what I've come to regard as standard operating procedure. I'm kind-of surprised you guys didn't put 1.3.0 (--> 1.3.x) onto a branch earlier and then just do the 1.4.x refactor right on the trunk.

I think both makes sense and is a good idea.

Then again, SOP hasn't ever created anything halfway as cool as geoserver before!

--saul

Justin Deoliveira wrote:

Hi all,

With 1.3.0 out, and development ramping up on 1.4.x, i think we need to decide how things will be organized in the repository in terms of branches vs trunk.

Right now things are laid out as follows:

1.3.x = trunk
1.4.x = branch
complex-features = branch of 1.4.x

So I guess the big question is should 1.4.x be made the new trunk and 1.3.x put out on a maintenance branch?

My recommendation would be as follows (and please feel free to disagree)

1.4.x = trunk
1.3.x = branch
complex-features = branch

Since 1.4.x is really just 1.3.x. + spring container + code broken up into modules it is still quite "stable". It passes all unit tests and ogc cite tests. So having it as trunk isn't really all that different then the way things are today. The only big thing is the new build system which a few people have successfully been able to use.

Since the complex stuff is going to be pretty shaky for a couple of weeks to come, it needs to stay out on a branch for a little while yet before getting merged back onto 1.4.x / trunk / whatever we decide.

So this email is just really to start up conversation about what people think. And possibly come to come to a resolution about it.

-Justin

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

+1 here
On Tuesday 21 February 2006 21:26, Justin Deoliveira wrote:

Hi all,

With 1.3.0 out, and development ramping up on 1.4.x, i think we need to
decide how things will be organized in the repository in terms of
branches vs trunk.

Right now things are laid out as follows:

1.3.x = trunk
1.4.x = branch
complex-features = branch of 1.4.x

So I guess the big question is should 1.4.x be made the new trunk and
1.3.x put out on a maintenance branch?

My recommendation would be as follows (and please feel free to disagree)

1.4.x = trunk
1.3.x = branch
complex-features = branch

Since 1.4.x is really just 1.3.x. + spring container + code broken up
into modules it is still quite "stable". It passes all unit tests and
ogc cite tests. So having it as trunk isn't really all that different
then the way things are today. The only big thing is the new build
system which a few people have successfully been able to use.

Since the complex stuff is going to be pretty shaky for a couple of
weeks to come, it needs to stay out on a branch for a little while yet
before getting merged back onto 1.4.x / trunk / whatever we decide.

So this email is just really to start up conversation about what people
think. And possibly come to come to a resolution about it.

-Justin

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90

Hi all,
I think your recommendation sounds great. I have two small questions
which might have been already answered.

1> Is there a road map for 1.4.x?

2>In case I had some minor improvements for the 1.3.x WMS what
proceudre should I follow? I guess just committing them is not the
right one :-).

Simone.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 2/21/06, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Good, always good to know i am not totally out to lunch :). And your
opinion definitley carries weight here Saul.

-Justin

Saul Farber wrote:
> I'm not sure my opinion carries a lot of weight, but what you propose is
> pretty much what I've come to regard as standard operating procedure.
> I'm kind-of surprised you guys didn't put 1.3.0 (--> 1.3.x) onto a
> branch earlier and then just do the 1.4.x refactor right on the trunk.
>
> I think both makes sense and is a good idea.
>
> Then again, SOP hasn't ever created anything halfway as cool as
> geoserver before!
>
> --saul
>
> Justin Deoliveira wrote:
>
>> Hi all,
>>
>> With 1.3.0 out, and development ramping up on 1.4.x, i think we need
>> to decide how things will be organized in the repository in terms of
>> branches vs trunk.
>>
>> Right now things are laid out as follows:
>>
>> 1.3.x = trunk
>> 1.4.x = branch
>> complex-features = branch of 1.4.x
>>
>> So I guess the big question is should 1.4.x be made the new trunk and
>> 1.3.x put out on a maintenance branch?
>>
>> My recommendation would be as follows (and please feel free to disagree)
>>
>> 1.4.x = trunk
>> 1.3.x = branch
>> complex-features = branch
>>
>> Since 1.4.x is really just 1.3.x. + spring container + code broken up
>> into modules it is still quite "stable". It passes all unit tests and
>> ogc cite tests. So having it as trunk isn't really all that different
>> then the way things are today. The only big thing is the new build
>> system which a few people have successfully been able to use.
>>
>> Since the complex stuff is going to be pretty shaky for a couple of
>> weeks to come, it needs to stay out on a branch for a little while yet
>> before getting merged back onto 1.4.x / trunk / whatever we decide.
>>
>> So this email is just really to start up conversation about what
>> people think. And possibly come to come to a resolution about it.
>>
>> -Justin
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>> files
>> for problems? Stop! Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

Simone:

If 1.4.x becomes the new trunk, will the WCS releases be aligned with
it from then on?

Alex

On 2/21/06, Simone Giannecchini <simboss1@...403...> wrote:

Hi all,
I think your recommendation sounds great. I have two small questions
which might have been already answered.

1> Is there a road map for 1.4.x?

2>In case I had some minor improvements for the 1.3.x WMS what
proceudre should I follow? I guess just committing them is not the
right one :-).

Simone.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 2/21/06, Justin Deoliveira <jdeolive@...13...> wrote:
> Good, always good to know i am not totally out to lunch :). And your
> opinion definitley carries weight here Saul.
>
> -Justin
>
> Saul Farber wrote:
> > I'm not sure my opinion carries a lot of weight, but what you propose is
> > pretty much what I've come to regard as standard operating procedure.
> > I'm kind-of surprised you guys didn't put 1.3.0 (--> 1.3.x) onto a
> > branch earlier and then just do the 1.4.x refactor right on the trunk.
> >
> > I think both makes sense and is a good idea.
> >
> > Then again, SOP hasn't ever created anything halfway as cool as
> > geoserver before!
> >
> > --saul
> >
> > Justin Deoliveira wrote:
> >
> >> Hi all,
> >>
> >> With 1.3.0 out, and development ramping up on 1.4.x, i think we need
> >> to decide how things will be organized in the repository in terms of
> >> branches vs trunk.
> >>
> >> Right now things are laid out as follows:
> >>
> >> 1.3.x = trunk
> >> 1.4.x = branch
> >> complex-features = branch of 1.4.x
> >>
> >> So I guess the big question is should 1.4.x be made the new trunk and
> >> 1.3.x put out on a maintenance branch?
> >>
> >> My recommendation would be as follows (and please feel free to disagree)
> >>
> >> 1.4.x = trunk
> >> 1.3.x = branch
> >> complex-features = branch
> >>
> >> Since 1.4.x is really just 1.3.x. + spring container + code broken up
> >> into modules it is still quite "stable". It passes all unit tests and
> >> ogc cite tests. So having it as trunk isn't really all that different
> >> then the way things are today. The only big thing is the new build
> >> system which a few people have successfully been able to use.
> >>
> >> Since the complex stuff is going to be pretty shaky for a couple of
> >> weeks to come, it needs to stay out on a branch for a little while yet
> >> before getting merged back onto 1.4.x / trunk / whatever we decide.
> >>
> >> So this email is just really to start up conversation about what
> >> people think. And possibly come to come to a resolution about it.
> >>
> >> -Justin
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> >> files
> >> for problems? Stop! Download the new AJAX search engine that makes
> >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> >> _______________________________________________
> >> Geoserver-devel mailing list
> >> Geoserver-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

--

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hi alex,
actual plan is to align the 0.3 to 1.3.x then 0.4 will be based on 1.4.x.

Simone.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 2/21/06, Alexander Petkov <greenkov@anonymised.com> wrote:

Simone:

If 1.4.x becomes the new trunk, will the WCS releases be aligned with
it from then on?

Alex

On 2/21/06, Simone Giannecchini <simboss1@anonymised.com> wrote:
> Hi all,
> I think your recommendation sounds great. I have two small questions
> which might have been already answered.
>
> 1> Is there a road map for 1.4.x?
>
> 2>In case I had some minor improvements for the 1.3.x WMS what
> proceudre should I follow? I guess just committing them is not the
> right one :-).
>
> Simone.
>
> °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
> Simone Giannecchini
> Software Engineer
> Freelance Consultant
>
> http://simboss.wordpress.com/
>
> °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
>
>
> On 2/21/06, Justin Deoliveira <jdeolive@anonymised.com> wrote:
> > Good, always good to know i am not totally out to lunch :). And your
> > opinion definitley carries weight here Saul.
> >
> > -Justin
> >
> > Saul Farber wrote:
> > > I'm not sure my opinion carries a lot of weight, but what you propose is
> > > pretty much what I've come to regard as standard operating procedure.
> > > I'm kind-of surprised you guys didn't put 1.3.0 (--> 1.3.x) onto a
> > > branch earlier and then just do the 1.4.x refactor right on the trunk.
> > >
> > > I think both makes sense and is a good idea.
> > >
> > > Then again, SOP hasn't ever created anything halfway as cool as
> > > geoserver before!
> > >
> > > --saul
> > >
> > > Justin Deoliveira wrote:
> > >
> > >> Hi all,
> > >>
> > >> With 1.3.0 out, and development ramping up on 1.4.x, i think we need
> > >> to decide how things will be organized in the repository in terms of
> > >> branches vs trunk.
> > >>
> > >> Right now things are laid out as follows:
> > >>
> > >> 1.3.x = trunk
> > >> 1.4.x = branch
> > >> complex-features = branch of 1.4.x
> > >>
> > >> So I guess the big question is should 1.4.x be made the new trunk and
> > >> 1.3.x put out on a maintenance branch?
> > >>
> > >> My recommendation would be as follows (and please feel free to disagree)
> > >>
> > >> 1.4.x = trunk
> > >> 1.3.x = branch
> > >> complex-features = branch
> > >>
> > >> Since 1.4.x is really just 1.3.x. + spring container + code broken up
> > >> into modules it is still quite "stable". It passes all unit tests and
> > >> ogc cite tests. So having it as trunk isn't really all that different
> > >> then the way things are today. The only big thing is the new build
> > >> system which a few people have successfully been able to use.
> > >>
> > >> Since the complex stuff is going to be pretty shaky for a couple of
> > >> weeks to come, it needs to stay out on a branch for a little while yet
> > >> before getting merged back onto 1.4.x / trunk / whatever we decide.
> > >>
> > >> So this email is just really to start up conversation about what
> > >> people think. And possibly come to come to a resolution about it.
> > >>
> > >> -Justin
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> -------------------------------------------------------
> > >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > >> files
> > >> for problems? Stop! Download the new AJAX search engine that makes
> > >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> > >> _______________________________________________
> > >> Geoserver-devel mailing list
> > >> Geoserver-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
>
>
> --
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Even if it doesn't become the new trunk immediately, the WCS releases should still be aligned with 1.4.x, since it will eventually become trunk, and WCS won't be released in the core GeoServer releases until that point. All experimental and future work should be done against the latest GeoServer development, if it wants to be released mainstream eventually, whether we call it 1.4.x or trunk.

Alexander Petkov wrote:

Simone:

If 1.4.x becomes the new trunk, will the WCS releases be aligned with
it from then on?

Alex

On 2/21/06, Simone Giannecchini <simboss1@anonymised.com> wrote:

Hi all,
I think your recommendation sounds great. I have two small questions
which might have been already answered.

1> Is there a road map for 1.4.x?

2>In case I had some minor improvements for the 1.3.x WMS what
proceudre should I follow? I guess just committing them is not the
right one :-).

Simone.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 2/21/06, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Good, always good to know i am not totally out to lunch :). And your
opinion definitley carries weight here Saul.

-Justin

Saul Farber wrote:

I'm not sure my opinion carries a lot of weight, but what you propose is
pretty much what I've come to regard as standard operating procedure.
I'm kind-of surprised you guys didn't put 1.3.0 (--> 1.3.x) onto a
branch earlier and then just do the 1.4.x refactor right on the trunk.

I think both makes sense and is a good idea.

Then again, SOP hasn't ever created anything halfway as cool as
geoserver before!

--saul

Justin Deoliveira wrote:

Hi all,

With 1.3.0 out, and development ramping up on 1.4.x, i think we need
to decide how things will be organized in the repository in terms of
branches vs trunk.

Right now things are laid out as follows:

1.3.x = trunk
1.4.x = branch
complex-features = branch of 1.4.x

So I guess the big question is should 1.4.x be made the new trunk and
1.3.x put out on a maintenance branch?

My recommendation would be as follows (and please feel free to disagree)

1.4.x = trunk
1.3.x = branch
complex-features = branch

Since 1.4.x is really just 1.3.x. + spring container + code broken up
into modules it is still quite "stable". It passes all unit tests and
ogc cite tests. So having it as trunk isn't really all that different
then the way things are today. The only big thing is the new build
system which a few people have successfully been able to use.

Since the complex stuff is going to be pretty shaky for a couple of
weeks to come, it needs to stay out on a branch for a little while yet
before getting merged back onto 1.4.x / trunk / whatever we decide.

So this email is just really to start up conversation about what
people think. And possibly come to come to a resolution about it.

-Justin

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

N�HY޵隊X���'���u���[�������
ަ�k��!���W�~�鮆�zk��C� 塧m����@^ǚ��^��z�Z�f�z�j�!�x2���a����ɫ,��� a{a� �,�H��4�m�����Z��jY�w��ǥrge�I"w]7�}��ݷӏ:u�u�^��g����z�^��fj)b� b�ў�ǫ���z�+-��.�ǟ����a��l��b��,���y�+��޷�b��?�+-�w��a����z�^�

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

Hi Chris,
I see your point ad I agree on it but the fundings I have right now
for the branch require me to come up with a new version pretty soon,
therefore for this new version I do not think I will be able to
re-branch from 1.4.x.

As soon as the new version will be mature mature, we will switch to
1.4.x for sure.

I know I have been quite absent from the various discussions lately,
but I have been working behind the curtains in order to convince
people in nato to adopt, where possible, the geoserver/geotools stack.
I am also trying to get involved Pisa state university (actually I
have a guy doing his master thesis with me on coverages). Things seem
to be turning fine even if slowly since these kind of organization
usually move very slowly.

Simone.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 2/21/06, Chris Holmes <cholmes@...13...> wrote:

Even if it doesn't become the new trunk immediately, the WCS releases
should still be aligned with 1.4.x, since it will eventually become
trunk, and WCS won't be released in the core GeoServer releases until
that point. All experimental and future work should be done against the
latest GeoServer development, if it wants to be released mainstream
eventually, whether we call it 1.4.x or trunk.

Alexander Petkov wrote:
> Simone:
>
> If 1.4.x becomes the new trunk, will the WCS releases be aligned with
> it from then on?
>
> Alex
>
> On 2/21/06, Simone Giannecchini <simboss1@...403...> wrote:
>
>>Hi all,
>>I think your recommendation sounds great. I have two small questions
>>which might have been already answered.
>>
>>1> Is there a road map for 1.4.x?
>>
>>2>In case I had some minor improvements for the 1.3.x WMS what
>>proceudre should I follow? I guess just committing them is not the
>>right one :-).
>>
>>Simone.
>>
>>°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
>>Simone Giannecchini
>>Software Engineer
>>Freelance Consultant
>>
>>http://simboss.wordpress.com/
>>
>>°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
>>
>>
>>On 2/21/06, Justin Deoliveira <jdeolive@...13...> wrote:
>>
>>>Good, always good to know i am not totally out to lunch :). And your
>>>opinion definitley carries weight here Saul.
>>>
>>>-Justin
>>>
>>>Saul Farber wrote:
>>>
>>>>I'm not sure my opinion carries a lot of weight, but what you propose is
>>>>pretty much what I've come to regard as standard operating procedure.
>>>>I'm kind-of surprised you guys didn't put 1.3.0 (--> 1.3.x) onto a
>>>>branch earlier and then just do the 1.4.x refactor right on the trunk.
>>>>
>>>>I think both makes sense and is a good idea.
>>>>
>>>>Then again, SOP hasn't ever created anything halfway as cool as
>>>>geoserver before!
>>>>
>>>>--saul
>>>>
>>>>Justin Deoliveira wrote:
>>>>
>>>>
>>>>>Hi all,
>>>>>
>>>>>With 1.3.0 out, and development ramping up on 1.4.x, i think we need
>>>>>to decide how things will be organized in the repository in terms of
>>>>>branches vs trunk.
>>>>>
>>>>>Right now things are laid out as follows:
>>>>>
>>>>>1.3.x = trunk
>>>>>1.4.x = branch
>>>>>complex-features = branch of 1.4.x
>>>>>
>>>>>So I guess the big question is should 1.4.x be made the new trunk and
>>>>>1.3.x put out on a maintenance branch?
>>>>>
>>>>>My recommendation would be as follows (and please feel free to disagree)
>>>>>
>>>>>1.4.x = trunk
>>>>>1.3.x = branch
>>>>>complex-features = branch
>>>>>
>>>>>Since 1.4.x is really just 1.3.x. + spring container + code broken up
>>>>>into modules it is still quite "stable". It passes all unit tests and
>>>>>ogc cite tests. So having it as trunk isn't really all that different
>>>>>then the way things are today. The only big thing is the new build
>>>>>system which a few people have successfully been able to use.
>>>>>
>>>>>Since the complex stuff is going to be pretty shaky for a couple of
>>>>>weeks to come, it needs to stay out on a branch for a little while yet
>>>>>before getting merged back onto 1.4.x / trunk / whatever we decide.
>>>>>
>>>>>So this email is just really to start up conversation about what
>>>>>people think. And possibly come to come to a resolution about it.
>>>>>
>>>>>-Justin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>>>>files
>>>>>for problems? Stop! Download the new AJAX search engine that makes
>>>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>>>>>_______________________________________________
>>>>>Geoserver-devel mailing list
>>>>>Geoserver-devel@lists.sourceforge.net
>>>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>for problems? Stop! Download the new AJAX search engine that makes
>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>>>_______________________________________________
>>>Geoserver-devel mailing list
>>>Geoserver-devel@lists.sourceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
>>
>>--
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems? Stop! Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
>>_______________________________________________
>>Geoserver-devel mailing list
>>Geoserver-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
> N�HY޵隊X���'���u���[�������
> ަ�k��!���W�~�鮆�zk��C� 塧m����@^ǚ��^��z�Z�f�z�j�!�x2���a����ɫ,��� a{a� �,�H��4�m�����Z��jY�w��ǥrge�I"w]7�}��ݷӏ:u�u�^��g����z�^��fj)b� b�ў�ǫ���z�+-��.�ǟ����a��l��b��,���y�+��޷�b��?�+-�w��a����z�^�

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

Simone Giannecchini wrote:

Hi Chris,
I see your point ad I agree on it but the fundings I have right now
for the branch require me to come up with a new version pretty soon,
therefore for this new version I do not think I will be able to
re-branch from 1.4.x.

As soon as the new version will be mature mature, we will switch to
1.4.x for sure.

Oh, that is totally and completely fine. To require you to upgrade as soon as we make the switch, changing lots around, is ridiculous, and just doesn't respect your work and deadlines. It's great news that you're planning on it for the 0.4 release, indeed that's actually sooner than I was expecting. My only point was that it should be at _some_ point, before it was integrated with the mainstream. Not to dictate that all releases have to be made off of the latest.

I know I have been quite absent from the various discussions lately,
but I have been working behind the curtains in order to convince
people in nato to adopt, where possible, the geoserver/geotools stack.
I am also trying to get involved Pisa state university (actually I
have a guy doing his master thesis with me on coverages). Things seem
to be turning fine even if slowly since these kind of organization
usually move very slowly.

Awesome. Your work is very appreciated, and I'm excited for the day that it becomes a core part of GeoServer. Oh yeah, FrankW said he has a guy working on java bindings for GDAL, which would definitely be worth investigating when all the interfaces have settled.

best regards,

Chris

Simone.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 2/21/06, Chris Holmes <cholmes@anonymised.com> wrote:

Even if it doesn't become the new trunk immediately, the WCS releases
should still be aligned with 1.4.x, since it will eventually become
trunk, and WCS won't be released in the core GeoServer releases until
that point. All experimental and future work should be done against the
latest GeoServer development, if it wants to be released mainstream
eventually, whether we call it 1.4.x or trunk.

Alexander Petkov wrote:

Simone:

If 1.4.x becomes the new trunk, will the WCS releases be aligned with
it from then on?

Alex

On 2/21/06, Simone Giannecchini <simboss1@anonymised.com> wrote:

Hi all,
I think your recommendation sounds great. I have two small questions
which might have been already answered.

1> Is there a road map for 1.4.x?

2>In case I had some minor improvements for the 1.3.x WMS what
proceudre should I follow? I guess just committing them is not the
right one :-).

Simone.

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

On 2/21/06, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Good, always good to know i am not totally out to lunch :). And your
opinion definitley carries weight here Saul.

-Justin

Saul Farber wrote:

I'm not sure my opinion carries a lot of weight, but what you propose is
pretty much what I've come to regard as standard operating procedure.
I'm kind-of surprised you guys didn't put 1.3.0 (--> 1.3.x) onto a
branch earlier and then just do the 1.4.x refactor right on the trunk.

I think both makes sense and is a good idea.

Then again, SOP hasn't ever created anything halfway as cool as
geoserver before!

--saul

Justin Deoliveira wrote:

Hi all,

With 1.3.0 out, and development ramping up on 1.4.x, i think we need
to decide how things will be organized in the repository in terms of
branches vs trunk.

Right now things are laid out as follows:

1.3.x = trunk
1.4.x = branch
complex-features = branch of 1.4.x

So I guess the big question is should 1.4.x be made the new trunk and
1.3.x put out on a maintenance branch?

My recommendation would be as follows (and please feel free to disagree)

1.4.x = trunk
1.3.x = branch
complex-features = branch

Since 1.4.x is really just 1.3.x. + spring container + code broken up
into modules it is still quite "stable". It passes all unit tests and
ogc cite tests. So having it as trunk isn't really all that different
then the way things are today. The only big thing is the new build
system which a few people have successfully been able to use.

Since the complex stuff is going to be pretty shaky for a couple of
weeks to come, it needs to stay out on a branch for a little while yet
before getting merged back onto 1.4.x / trunk / whatever we decide.

So this email is just really to start up conversation about what
people think. And possibly come to come to a resolution about it.

-Justin

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

N�HY޵隊X���'���u���[�������
ަ�k��!���W�~�鮆�zk��C� 塧m����@^ǚ��^��z�Z�f�z�j�!�x2���a����ɫ,��� a{a� �,�H��4�m�����Z��jY�w��ǥrge�I"w]7�}��ݷӏ:u�u�^��g����z�^��fj)b� b�ў�ǫ���z�+-��.�ǟ����a��l��b��,���y�+��޷�b��?�+-�w��a����z�^�

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

If 1.4.x is as stable as 1.3.x, then I say we switch 1.4.x to trunk.
But I definitely feel that every release we do has to be an improvement on the last. So if a bunch of stuff is broken, we need to hold off. I would also like to wait until 1.3.1 is out (within the next week or so) before we merge.

The existing documentation will have to be changed to reflect the new build system. And it will take a while for all the developers to get up to speed on how Spring works and where everything lives. So any documentation on the new structure (pictures especially) and what has changed since 1.3.x, will be a huge plus.

As for the complex stuff, I think more than a few weeks will be needed to straighten it out and it will have to wait to go onto trunk. It will have to be spotless because it is such a huge change.

Brent Owens
(The Open Planning Project)

Justin Deoliveira wrote:

Hi all,

With 1.3.0 out, and development ramping up on 1.4.x, i think we need to decide how things will be organized in the repository in terms of branches vs trunk.

Right now things are laid out as follows:

1.3.x = trunk
1.4.x = branch
complex-features = branch of 1.4.x

So I guess the big question is should 1.4.x be made the new trunk and 1.3.x put out on a maintenance branch?

My recommendation would be as follows (and please feel free to disagree)

1.4.x = trunk
1.3.x = branch
complex-features = branch

Since 1.4.x is really just 1.3.x. + spring container + code broken up into modules it is still quite "stable". It passes all unit tests and ogc cite tests. So having it as trunk isn't really all that different then the way things are today. The only big thing is the new build system which a few people have successfully been able to use.

Since the complex stuff is going to be pretty shaky for a couple of weeks to come, it needs to stay out on a branch for a little while yet before getting merged back onto 1.4.x / trunk / whatever we decide.

So this email is just really to start up conversation about what people think. And possibly come to come to a resolution about it.

-Justin

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel