Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

My Take: - rename Beta to RC - rather than having an RC2 adding one more release to the existing train maybe with a shorter timeline if/as needed The rationale is giving users something testable that does not carry the Beta or RC tag as soon as possible and account for a initial shorter release

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

There was some discussion on this topic in the PMC meeting. Salient points: - Should we rename the beta the RC (Basically, the fork/RC would now be 1 month before the .0 release and there wouldn't be a beta release anymore). - The most useful naming scheme for would be whatever people

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

On Fri, Feb 16, 2018 at 8:47 AM, Jody Garnett wrote: > We could also cut the beta just to confirm master is releasable, and not > branch. Make the first release candidate the branch to achieve the same > effect. > > It has the advantage of less moving parts, but we do not

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

PR's for the associated doc changes here: - https://github.com/geotools/geotools/pull/1811 - https://github.com/geoserver/geoserver/pull/2763 We also have a release process diagram which includes the freeze. While not critical, that could be updated - does anyone have the source files for

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

First of all, the change seems reasonable, so +1 there. I have no issues with applying these changes right away for the beta release next week, and we can do a GSIP later. I'll also update the release docs while I do the release. Torben On Fri, Feb 16, 2018 at 8:30 AM, Andrea Aime

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

On Fri, Feb 16, 2018 at 11:44 AM, Ian Turton wrote: > I agree we hardly ever see any feedback before the .0 release. Which is a > shame but nothing we do seems to make a difference to customers. > Ah hem, "users" :-p Cheers Andrea == GeoServer Professional Services from

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

We could also cut the beta just to confirm master is releasable, and not branch. Make the first release candidate the branch to achieve the same effect. It has the advantage of less moving parts, but we do not get a code freeze to focus on bugs. But as you point out that is not happening so much.

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

On Fri, Feb 16, 2018 at 4:18 AM, Ben Caradoc-Davies wrote: > +1. It does seem that we are not getting much benefit from waiting until > RC to branch, and any fix would be applied to master and the new stable > before the .0 release. We could drop the RC altogether. The current

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

+1 Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

I don't have any voting power, just want to express my +1 towards that change ... and indeed I don't see the advantage of the RC release. If users don't provide feedback, bug fix doesn't happen ... what are the advantages of having the RC release ? On 02/16/2018 03:18 AM, Ben Caradoc-Davies

Re: [Geoserver-devel] Suggesting a small change in release procedures: can we cut the stable branch on beta?

+1. It does seem that we are not getting much benefit from waiting until RC to branch, and any fix would be applied to master and the new stable before the .0 release. We could drop the RC altogether. The current procedure incurs not only a delay but also the work of an extra release (the RC).