Thanks for the discussion, I am a bit indifferent about the options (just
so long as everyone is happy and we can plan appropriately).
--
Jody Garnett
On 17 June 2016 at 01:48, Andrea Aime <andrea.a...@geo-solutions.it> wrote:
> On Thu, Jun 16, 2016 at 8:13 PM, Simone Giannecchini <
> simone.giannecch...@geo-solutions.it> wrote:
>
>> Thinking...
>>
>> My first and foremost concern is stability for our clients so that's
>> why shortening the release cycle does not make me super happy.
>> If we want to chatch up with the old March/Sept timing I am ok with
>> shortening by 1M now and then another 1M next time.
>>
>> This way we will absorbe the 2.9 delay in two releases and I believe
>> people won't cut their wrists if we are one month off for a couple of
>> releases.
>>
>
> Right, it's less brutal than cutting 2.10.x down to a short 4 months cycle.
> So we'd have 2.10-beta September 18th and final October 18th,
> and 2.11-beta Feb 18th 2017 and 2.11 final March 18th 2017...
> And indeed as Ben notes, 2.9.2 would be the last one before 2.9.x
> gets into maintenance. Along with the shortened 2.11 release cycle,
> the users availability of 2.9.x would go down to 10 months instead of the
> usual 12.
>
> If instead we keep the development of 2.10 running till the next tick and
> thus release in March 2018, we'd have a long 2.9.x stable, getting to 2.9.4
> before getting into maintenance mode, and a longer 2.8.x too as a result.
> 2.10.x would get a 10 months development cycle, which will increase the
> pressure
> to backport stuff to 2.9.x I guess, and add some stabilization risk if too
> many new features accumulate.
> Can we venture a guess if this will materialize or not? like, how many
> core changes do people
> foresee for the next months? If most of the work is going to be on
> community or
> extension modules we'd have less of a risk of course, and it's also easier
> to just backport them to stable to get the out to the user community.
>
> For the sake of completeness, with Jody last time we also discussed a
> potential
> 9 months cycle, but if memory serves me right it was going to put releases
> in some hard to staff months of the year (and the "cycle" of release dates
> would be hard to
> remember, it would repeat every 36 months).... and of course the
> stabilization risk
> would be there at each release.
>
> Personally I'm a bit twisted between the first two options, seeing
> benefits and
> drawbacks in both.
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054 Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports. http://sdm.link/zohomanageengine
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
