[Geoserver-devel] Time boxed release mode: proposing some modifications

GeoServer GeoServer Developer
1

Hi,
me and Simone have been thinking about ways to improve the current release schedule based
on feedback we’re getting from users and customers.

What seems to be working: the 6 months development cycle keeps dev short enough that we
don’t make the GeoServer code too unstable in the process, and helps getting funding for
new features, as they get in a released version soon enough.
What seems to not be working: the monthly release and the fact we have the stable series
live for only six months. Indeed we received a number of complaints that “we can’t keep up
with you” and a general desire to have a stable series with bug fixes live a longer time,
as production installation don’t want to get on .0/.1/.2 releases, but by the time we get to .3
the residual life is rather short.

So we tried to devise a plan to have less frequent releases, and keep the life of a stable
branch longer, basically by:

  • having at any time two stable branches
  • each month release from one of those, but try to avoid doing multiple releases in the same month,
    besides the period in which the betas/rcs for the new series is coming out

We provided the tentative schedule here, and Jody added an alternate version in the second tab.
The first one is based on releasing bi-monthly in turns from the stable branches, Jody’s approach
is to release frequently at the beginning, each month right away, then every 3 months, then
wait 4 for the last optional release, which will be done if there is funding/interest:

https://docs.google.com/spreadsheet/ccc?key=0Aq3GF1EnUyHEdE9sVG54VzFpWHpXMmNlNkV0QjZVblE#gid=2

As you can see each branch goes through a few stages, development, stable, maintenance, and then
eventual LTS releases if there is resources to make them.

Looking at the spreadsheets right now I see the .0 releases are actually 5 months apart, that needs
some fixing for sure… but I guess the idea is there.

If you want to play with the timeline and create a new version of it in a separate tab please let
me know and I’ll give you write access to the document

Cheers
Andrea

–

== Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information ==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

2

We already discussed by voice about this proposal.

Just wanted to let the community be aware of my +1 about this.

···

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Alessio Fabiani
@alfa7691
Founder/Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 331 6233686

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

On Thu, Jan 23, 2014 at 10:50 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
me and Simone have been thinking about ways to improve the current release schedule based
on feedback we’re getting from users and customers.

What seems to be working: the 6 months development cycle keeps dev short enough that we
don’t make the GeoServer code too unstable in the process, and helps getting funding for
new features, as they get in a released version soon enough.
What seems to not be working: the monthly release and the fact we have the stable series
live for only six months. Indeed we received a number of complaints that “we can’t keep up
with you” and a general desire to have a stable series with bug fixes live a longer time,
as production installation don’t want to get on .0/.1/.2 releases, but by the time we get to .3
the residual life is rather short.

So we tried to devise a plan to have less frequent releases, and keep the life of a stable
branch longer, basically by:

  • having at any time two stable branches
  • each month release from one of those, but try to avoid doing multiple releases in the same month,
    besides the period in which the betas/rcs for the new series is coming out

We provided the tentative schedule here, and Jody added an alternate version in the second tab.
The first one is based on releasing bi-monthly in turns from the stable branches, Jody’s approach
is to release frequently at the beginning, each month right away, then every 3 months, then
wait 4 for the last optional release, which will be done if there is funding/interest:

https://docs.google.com/spreadsheet/ccc?key=0Aq3GF1EnUyHEdE9sVG54VzFpWHpXMmNlNkV0QjZVblE#gid=2

As you can see each branch goes through a few stages, development, stable, maintenance, and then
eventual LTS releases if there is resources to make them.

Looking at the spreadsheets right now I see the .0 releases are actually 5 months apart, that needs
some fixing for sure… but I guess the idea is there.

If you want to play with the timeline and create a new version of it in a separate tab please let
me know and I’ll give you write access to the document

Cheers
Andrea

–

== Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information ==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

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

3

Looks good to me.

My only thought is that our customers sometimes only want to change major versions once a year so maybe we could push the Optional LTS out to the full year?

Ian

···

On 23 January 2014 09:50, Andrea Aime <andrea.aime@anonymised.com68…> wrote:

Hi,
me and Simone have been thinking about ways to improve the current release schedule based
on feedback we’re getting from users and customers.

What seems to be working: the 6 months development cycle keeps dev short enough that we
don’t make the GeoServer code too unstable in the process, and helps getting funding for
new features, as they get in a released version soon enough.
What seems to not be working: the monthly release and the fact we have the stable series
live for only six months. Indeed we received a number of complaints that “we can’t keep up
with you” and a general desire to have a stable series with bug fixes live a longer time,
as production installation don’t want to get on .0/.1/.2 releases, but by the time we get to .3
the residual life is rather short.

So we tried to devise a plan to have less frequent releases, and keep the life of a stable
branch longer, basically by:

  • having at any time two stable branches
  • each month release from one of those, but try to avoid doing multiple releases in the same month,
    besides the period in which the betas/rcs for the new series is coming out

We provided the tentative schedule here, and Jody added an alternate version in the second tab.
The first one is based on releasing bi-monthly in turns from the stable branches, Jody’s approach
is to release frequently at the beginning, each month right away, then every 3 months, then
wait 4 for the last optional release, which will be done if there is funding/interest:

https://docs.google.com/spreadsheet/ccc?key=0Aq3GF1EnUyHEdE9sVG54VzFpWHpXMmNlNkV0QjZVblE#gid=2

As you can see each branch goes through a few stages, development, stable, maintenance, and then
eventual LTS releases if there is resources to make them.

Looking at the spreadsheets right now I see the .0 releases are actually 5 months apart, that needs
some fixing for sure… but I guess the idea is there.

If you want to play with the timeline and create a new version of it in a separate tab please let
me know and I’ll give you write access to the document

Cheers
Andrea

–

== Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information ==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

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

–
Ian Turton

4

+1 here

I believe this is much needed.
Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

On Thu, Jan 23, 2014 at 11:46 AM, Alessio Fabiani
<alessio.fabiani@anonymised.com> wrote:

We already discussed by voice about this proposal.

Just wanted to let the community be aware of my +1 about this.

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Alessio Fabiani
@alfa7691
Founder/Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 331 6233686

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

On Thu, Jan 23, 2014 at 10:50 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

Hi,
me and Simone have been thinking about ways to improve the current release
schedule based
on feedback we're getting from users and customers.

What seems to be working: the 6 months development cycle keeps dev short
enough that we
don't make the GeoServer code too unstable in the process, and helps
getting funding for
new features, as they get in a released version soon enough.
What seems to not be working: the monthly release and the fact we have the
stable series
live for only six months. Indeed we received a number of complaints that
"we can't keep up
with you" and a general desire to have a stable series with bug fixes live
a longer time,
as production installation don't want to get on .0/.1/.2 releases, but by
the time we get to .3
the residual life is rather short.

So we tried to devise a plan to have less frequent releases, and keep the
life of a stable
branch longer, basically by:
* having at any time two stable branches
* each month release from one of those, but try to avoid doing multiple
releases in the same month,
  besides the period in which the betas/rcs for the new series is coming
out

We provided the tentative schedule here, and Jody added an alternate
version in the second tab.
The first one is based on releasing bi-monthly in turns from the stable
branches, Jody's approach
is to release frequently at the beginning, each month right away, then
every 3 months, then
wait 4 for the last optional release, which will be done if there is
funding/interest:

https://docs.google.com/spreadsheet/ccc?key=0Aq3GF1EnUyHEdE9sVG54VzFpWHpXMmNlNkV0QjZVblE#gid=2

As you can see each branch goes through a few stages, development, stable,
maintenance, and then
eventual LTS releases if there is resources to make them.

Looking at the spreadsheets right now I see the .0 releases are actually 5
months apart, that needs
some fixing for sure... but I guess the idea is there.

If you want to play with the timeline and create a new version of it in a
separate tab please let
me know and I'll give you write access to the document

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.

http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

Dear Ian,
that is the idea, instead of 6 months, each release would last for
around 1 year.

Did I miss anything?

Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

On Thu, Jan 23, 2014 at 12:41 PM, Ian Turton <ijturton@anonymised.com> wrote:

Looks good to me.

My only thought is that our customers sometimes only want to change major
versions once a year so maybe we could push the Optional LTS out to the full
year?

Ian

On 23 January 2014 09:50, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
me and Simone have been thinking about ways to improve the current release
schedule based
on feedback we're getting from users and customers.

What seems to be working: the 6 months development cycle keeps dev short
enough that we
don't make the GeoServer code too unstable in the process, and helps
getting funding for
new features, as they get in a released version soon enough.
What seems to not be working: the monthly release and the fact we have the
stable series
live for only six months. Indeed we received a number of complaints that
"we can't keep up
with you" and a general desire to have a stable series with bug fixes live
a longer time,
as production installation don't want to get on .0/.1/.2 releases, but by
the time we get to .3
the residual life is rather short.

So we tried to devise a plan to have less frequent releases, and keep the
life of a stable
branch longer, basically by:
* having at any time two stable branches
* each month release from one of those, but try to avoid doing multiple
releases in the same month,
  besides the period in which the betas/rcs for the new series is coming
out

We provided the tentative schedule here, and Jody added an alternate
version in the second tab.
The first one is based on releasing bi-monthly in turns from the stable
branches, Jody's approach
is to release frequently at the beginning, each month right away, then
every 3 months, then
wait 4 for the last optional release, which will be done if there is
funding/interest:

https://docs.google.com/spreadsheet/ccc?key=0Aq3GF1EnUyHEdE9sVG54VzFpWHpXMmNlNkV0QjZVblE#gid=2

As you can see each branch goes through a few stages, development, stable,
maintenance, and then
eventual LTS releases if there is resources to make them.

Looking at the spreadsheets right now I see the .0 releases are actually 5
months apart, that needs
some fixing for sure... but I guess the idea is there.

If you want to play with the timeline and create a new version of it in a
separate tab please let
me know and I'll give you write access to the document

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.

http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Ian Turton

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

On 23 January 2014 11:46, Simone Giannecchini <
simone.giannecchini@anonymised.com> wrote:

Dear Ian,
that is the idea, instead of 6 months, each release would last for
around 1 year.

Did I miss anything?

No you are quiet right I was counting the top row and hadn't noticed that
we've already had some 2.4 releases before it starts. :slight_smile:

Ian

7

cool

I proposed this to Andrea exactly because we got "complaints" about
moving too fast with releases, hence your feedback is valuable for me
as it
shows this might solve a common issue.

Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

On Thu, Jan 23, 2014 at 12:50 PM, Ian Turton <ijturton@anonymised.com> wrote:

On 23 January 2014 11:46, Simone Giannecchini
<simone.giannecchini@anonymised.com> wrote:

Dear Ian,
that is the idea, instead of 6 months, each release would last for
around 1 year.

Did I miss anything?

No you are quiet right I was counting the top row and hadn't noticed that
we've already had some 2.4 releases before it starts. :slight_smile:

Ian

8

I like the idea as well. Indeed i think the stable release changing every 6 months is impractical for most “real” geoserver deployments. Actually in my experience even a year is too fast. In a few organizations I have seen it takes a year just to get a new software version approved :slight_smile: But I think it’s a reasonable compromise between stability and keeping the project moving with feature development. So +1 from me.

···

On Thu, Jan 23, 2014 at 4:59 AM, Simone Giannecchini <simone.giannecchini@…1268…> wrote:

cool

I proposed this to Andrea exactly because we got “complaints” about
moving too fast with releases, hence your feedback is valuable for me
as it
shows this might solve a common issue.

Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

On Thu, Jan 23, 2014 at 12:50 PM, Ian Turton <ijturton@anonymised.com.> wrote:

On 23 January 2014 11:46, Simone Giannecchini
<simone.giannecchini@anonymised.com> wrote:

Dear Ian,
that is the idea, instead of 6 months, each release would last for
around 1 year.

Did I miss anything?

No you are quiet right I was counting the top row and hadn’t noticed that
we’ve already had some 2.4 releases before it starts. :slight_smile:

Ian

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

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

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

9

On Thu, Jan 23, 2014 at 10:50 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

Looking at the spreadsheets right now I see the .0 releases are actually 5
months apart, that needs
some fixing for sure... but I guess the idea is there.

Hi all,
nice to hear there is agreement on the need for a change.
Shall we get down to specifics?

I've fixed the timelines so that we have the .0 releases regularly in march
and September.
I like both layout, the first one has the advantage of simplicity (and it's
easy to remember
and predict releases), the other one matches the reality of a software
project, you have less
and less development in a stable branch over time and thus it makes sense
to have
less frequent releases.

One unpleasant "feature" of the second is that we get to make RC, stable
and maintenance
all in the same month (and RCs are two, so it's 4 releases in that month).
That needs to be fixed imho.

What do others think?

Ah, one thing is that in both models maintenance releases are optional,
they get done
only if there is enough changes, otherwise they get skipped

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

10

I am missing something in this discussion. What forces a customer to move to a new release? If you have 2.2.3 as your production version, you can take as long as you like moving to a new release. Usually the attraction of critical bugfixes or new features drives the timetable. Does this LTS concept mean that bugfixes will be back-ported to the LTS till a new LTS is released?

Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.

11

I added “tick” “tock” 6 month cycles to the spreadsheet for you, and updated my alternate proposal to be a bit more even (to address the “cannot keep up” criteria).

I am +1 for this idea, and would like to see if we can turn it into a proposal to confirm we are happy with the “development”/“stable”/“maintenance” language.

···

Jody Garnett

On Thu, Jan 23, 2014 at 8:50 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
me and Simone have been thinking about ways to improve the current release schedule based
on feedback we’re getting from users and customers.

What seems to be working: the 6 months development cycle keeps dev short enough that we
don’t make the GeoServer code too unstable in the process, and helps getting funding for
new features, as they get in a released version soon enough.
What seems to not be working: the monthly release and the fact we have the stable series
live for only six months. Indeed we received a number of complaints that “we can’t keep up
with you” and a general desire to have a stable series with bug fixes live a longer time,
as production installation don’t want to get on .0/.1/.2 releases, but by the time we get to .3
the residual life is rather short.

So we tried to devise a plan to have less frequent releases, and keep the life of a stable
branch longer, basically by:

  • having at any time two stable branches
  • each month release from one of those, but try to avoid doing multiple releases in the same month,
    besides the period in which the betas/rcs for the new series is coming out

We provided the tentative schedule here, and Jody added an alternate version in the second tab.
The first one is based on releasing bi-monthly in turns from the stable branches, Jody’s approach
is to release frequently at the beginning, each month right away, then every 3 months, then
wait 4 for the last optional release, which will be done if there is funding/interest:

https://docs.google.com/spreadsheet/ccc?key=0Aq3GF1EnUyHEdE9sVG54VzFpWHpXMmNlNkV0QjZVblE#gid=2

As you can see each branch goes through a few stages, development, stable, maintenance, and then
eventual LTS releases if there is resources to make them.

Looking at the spreadsheets right now I see the .0 releases are actually 5 months apart, that needs
some fixing for sure… but I guess the idea is there.

If you want to play with the timeline and create a new version of it in a separate tab please let
me know and I’ll give you write access to the document

Cheers
Andrea

–

== Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information ==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

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

12

+1. I think this is a good idea.

I think the main challenge in this new model is developer education!

Kind regards,
Ben.

On 23/01/14 17:50, Andrea Aime wrote:

me and Simone have been thinking about ways to improve the current
release schedule based
on feedback we're getting from users and customers.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

13

(apologies for long silence on stuff, have been taking some time away)

I think one thing we might consider is only doing LTS releases on like evens or odds, to potentially ease things on us more. The one thing that strikes me on these schedules is that LTS is just kind of ‘old’. The Ubuntu LTS concept is that every 2 years they release one that they commit to for much longer (5 years). So the conservative people just do that, and know they’ll always get fixes. See https://wiki.ubuntu.com/LTS

So it has people pick which stream, and I’m sure at 1.5 and 4 years there are very few improvements. But better to just have the one or two old solid one, that people can rest assured to just sit on, instead of just occasional old bug fixes on whatever old one.

In both charts it should be a small change, it’s just that you’d do 2.4.9, 2.4.10, 2.4.11 and even 2.4.12, and never do 2.5.6. If you want the 2.5 stuff in a super stable thing you wait for the next LTS, which is designated LTS more from the beginning. And this should hopefully be a bit less work while making the people who want stability happy.

I think no matter what it’d also be good to promote the LTS concept to people. So that they don’t feel like they ‘have to keep up’.

···

On Thu, Jan 23, 2014 at 10:38 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

+1. I think this is a good idea.

I think the main challenge in this new model is developer education!

Kind regards,
Ben.

On 23/01/14 17:50, Andrea Aime wrote:

me and Simone have been thinking about ways to improve the current
release schedule based
on feedback we’re getting from users and customers.

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

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

14

Er, right, still have some ‘send from’ things that go from opengeo, though it won’t work. So reply to this one, with my gmail.

···

On Thu, Jan 23, 2014 at 11:16 PM, Chris Holmes <cholmes@anonymised.com> wrote:

(apologies for long silence on stuff, have been taking some time away)

I think one thing we might consider is only doing LTS releases on like evens or odds, to potentially ease things on us more. The one thing that strikes me on these schedules is that LTS is just kind of ‘old’. The Ubuntu LTS concept is that every 2 years they release one that they commit to for much longer (5 years). So the conservative people just do that, and know they’ll always get fixes. See https://wiki.ubuntu.com/LTS

So it has people pick which stream, and I’m sure at 1.5 and 4 years there are very few improvements. But better to just have the one or two old solid one, that people can rest assured to just sit on, instead of just occasional old bug fixes on whatever old one.

In both charts it should be a small change, it’s just that you’d do 2.4.9, 2.4.10, 2.4.11 and even 2.4.12, and never do 2.5.6. If you want the 2.5 stuff in a super stable thing you wait for the next LTS, which is designated LTS more from the beginning. And this should hopefully be a bit less work while making the people who want stability happy.

I think no matter what it’d also be good to promote the LTS concept to people. So that they don’t feel like they ‘have to keep up’.

On Thu, Jan 23, 2014 at 10:38 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

+1. I think this is a good idea.

I think the main challenge in this new model is developer education!

Kind regards,
Ben.

On 23/01/14 17:50, Andrea Aime wrote:

me and Simone have been thinking about ways to improve the current
release schedule based
on feedback we’re getting from users and customers.

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

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

15

On Thu, Jan 23, 2014 at 9:06 PM, Phil Scadden <p.scadden@anonymised.com> wrote:

I am missing something in this discussion. What forces a customer to
move to a new release? If you have 2.2.3 as your production version, you
can take as long as you like moving to a new release. Usually the
attraction of critical bugfixes or new features drives the timetable.

Not always, in some environments they have a policy of having the latest
patches.
Given we don't have a mechanism to issue security patches (that would have
to be operating system and container specific I'm afraid), people just
upgrade
their installations.

Does this LTS concept mean that bugfixes will be back-ported to the LTS
till a new LTS is released?

The idea was to backport bug fixes that are easy to backport (a git
cherry-pick
away with no conflicts) or that have specific funding for the backport

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

16

On Fri, Jan 24, 2014 at 5:16 AM, Chris Holmes <cholmes@anonymised.com> wrote:

(apologies for long silence on stuff, have been taking some time away)

I think one thing we might consider is only doing LTS releases on like
evens or odds, to potentially ease things on us more. The one thing that
strikes me on these schedules is that LTS is just kind of 'old'. The Ubuntu
LTS concept is that every 2 years they release one that they commit to for
much longer (5 years). So the conservative people just do that, and know
they'll always get fixes. See https://wiki.ubuntu.com/LTS

Yep, familiar with the concept (using a Ubuntu LTS myself).

However, not sure this can apply to GeoServer for a couple of reasons.

The main one is that we'd be trying to bite more than we can chew, in terms
of resourcing.
Let's imagine we had a 1.5 years old LTS right now, that would be the 2.2.x
series, and generally speaking, something 4 branches behind the current
development series.
The development of GeoServer is still going at a rather high pace, doing a
backport of a fix becomes more and more hard as we just back in the
branches,
while doing a cherry-pick from dev to stable (one branch jump) normally
works without significant conflicts, a 4 branches jump will result in
conflicts very often,
and in a need of full rewrite of the patch also often enough.

What does that mean? That the bugfixes in questions are realistically going
to be backported only if you are under contract to do so, so, few of them.

Which brings me to the second source of concern: who is going to be
interested in a 1-2 years old release?
In my experience, no one, and I'm not talking hyphotetically, GeoSolutions
tried with "GeoServer enterprise", and it basically got no traction:
all of our customers want something out of the recent series, and then they
want that to be maintained.
A 1-2 years old releases is just lacking too much, mostly because we are
still going at a high pace.

That's why we are pushing a 1 year lifetime instead, it gets long enough
for conservative people to use, but not so long that people will just
ignore it due to lack of too many new features.

Point in case, the new precise GetFeatureInfo... there is a lot of interest
for it, and we've been asked already a few times "why is it not in 2.4.x?"
(the answer is, because it's not a simple bug fix, it's a major refactor).
Something like this lowers the interest in older releases a lot... a few
items like this and the interest in a 1 year old release, 2 cycles
of new features behind the curve, is already rather small.

Imho, LTS are great, but for stuff that is mostly rather stable and not
fast evolving as GeoServer still is, 2 years cycles are just impractical
from both the developer point of view (difficulty of backports) and from
the audience interest point of view (which also means, difficulty
in gathering funds to justify the extra effort to keep a LTS up this long).

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

17

Hi List,
If I can chip in as a general observer briefly.

Which brings me to the second source of concern: who is going to be interested in a 1-2 years old release?

From my readings of the user mailing lists, there are still people using 2.1.x and 2.2.x. I don’t know what proportion, but a quick google shows there have been posts stating the use of those versions within the last month.

On the issue of LTS - looking at Andrea’s spreadsheet it occurs to me that if the optional LTS releases are taken up, then 1/3rd of the time you’re going to end up with potentially four active releases at once (Optional LTS, LTS, Stable, Beta/RC). That’s rather a lot - a user may end up wondering which they should be going with.

I’d suggest there should only ever be one LTS active at a time, maybe for longer than 6 months. A year maybe?

Cheers,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

18

On Fri, Jan 24, 2014 at 2:28 PM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

Hi List,
If I can chip in as a general observer briefly.

Which brings me to the second source of concern: who is going to be
interested in a 1-2 years old release?

From my readings of the user mailing lists, there are still people using
2.1.x and 2.2.x. I don't know what proportion, but a quick google shows
there have been posts stating the use of those versions within the last
month.

Right. But in order for that to be viable, it has to be a portion of users
interested in support contracts or development projects.
Otherwise how do you justify spending hours backporting patches that will
conflict during the backport due to 12-18 months
of code changes in the middle.

I know this line of thinking will make the open source purist unhappy, but
we have to be realistic, how much spare
time work do we expect to get on the LTS branch (especially after you just
spent 40-50 hours of paid work on or
on top of that same project?)
Personally, if I have to spend spare time, I much prefer to work on
something new, it's time I take away from
family and leisure, if it's just boring, I simply won't work on it. Don't
know how other developers feel about it.

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

19

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

Fair point. Might it be worth asking the customers? How about a web survey? Distribute to the customers and post to the user list; include a question where the user specifies if they have commercial support and use that to determine the weight of the results for the LTS question.

As a bonus, with intelligent questioning this would give a good idea as to what everyone is using GeoServer for, what components etc and could benefit everyone in the longer term as development efforts could be directed in that direction.
Seems like it might be worth doing; off the top of my head I can’t think of many (any?) Open Source projects that seek user feedback in this manner.

Cheers,
Jonathan

Right. But in order for that to be viable, it has to be a portion of users interested in support contracts or development projects.
Otherwise how do you justify spending hours backporting patches that will conflict during the backport due to 12-18 months
of code changes in the middle.

20

All that makes good sense. I wasn’t actually advocating for putting more resources in to maintaining really long releases, and indeed I think the 1 year cycle is good. Was just suggesting the notion of not doing LTS for every release. So what I was aiming at was less work for developers. Basically instead of doing the LTS for every release, of old bug fixes, we’d just do it for say evens. So then when people are like ‘why is this simple bug fix not in 2.3.x’ you can say that only 2.4.x is LTS, so it’s the only one that gets the old backports.

And then from there just promote the idea of LTS a bit more for stable people. Every year they’d upgrade to the new LTS, when the next even gets to LTS status, instead of every six months. So like Jonathan is saying, we wouldn’t have LTS and optional LTS, there’d just be one LTS that stretches out.

···

On Fri, Jan 24, 2014 at 7:02 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jan 24, 2014 at 5:16 AM, Chris Holmes <cholmes@anonymised.com> wrote:

(apologies for long silence on stuff, have been taking some time away)

I think one thing we might consider is only doing LTS releases on like evens or odds, to potentially ease things on us more. The one thing that strikes me on these schedules is that LTS is just kind of ‘old’. The Ubuntu LTS concept is that every 2 years they release one that they commit to for much longer (5 years). So the conservative people just do that, and know they’ll always get fixes. See https://wiki.ubuntu.com/LTS

Yep, familiar with the concept (using a Ubuntu LTS myself).

However, not sure this can apply to GeoServer for a couple of reasons.

The main one is that we’d be trying to bite more than we can chew, in terms of resourcing.
Let’s imagine we had a 1.5 years old LTS right now, that would be the 2.2.x series, and generally speaking, something 4 branches behind the current development series.
The development of GeoServer is still going at a rather high pace, doing a backport of a fix becomes more and more hard as we just back in the branches,
while doing a cherry-pick from dev to stable (one branch jump) normally works without significant conflicts, a 4 branches jump will result in conflicts very often,
and in a need of full rewrite of the patch also often enough.

What does that mean? That the bugfixes in questions are realistically going to be backported only if you are under contract to do so, so, few of them.

Which brings me to the second source of concern: who is going to be interested in a 1-2 years old release?
In my experience, no one, and I’m not talking hyphotetically, GeoSolutions tried with “GeoServer enterprise”, and it basically got no traction:
all of our customers want something out of the recent series, and then they want that to be maintained.
A 1-2 years old releases is just lacking too much, mostly because we are still going at a high pace.

That’s why we are pushing a 1 year lifetime instead, it gets long enough for conservative people to use, but not so long that people will just
ignore it due to lack of too many new features.

Point in case, the new precise GetFeatureInfo… there is a lot of interest for it, and we’ve been asked already a few times “why is it not in 2.4.x?”
(the answer is, because it’s not a simple bug fix, it’s a major refactor).
Something like this lowers the interest in older releases a lot… a few items like this and the interest in a 1 year old release, 2 cycles
of new features behind the curve, is already rather small.

Imho, LTS are great, but for stuff that is mostly rather stable and not fast evolving as GeoServer still is, 2 years cycles are just impractical
from both the developer point of view (difficulty of backports) and from the audience interest point of view (which also means, difficulty
in gathering funds to justify the extra effort to keep a LTS up this long).

Cheers

Andrea

–

== Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information ==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it