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 c
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
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 get a code freeze
> to f
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 i
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
wrote:
> On
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 the experts! Visit htt
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.
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
> procedure incurs
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.
So +1 for me
Ian
On 16 February 2018 at 09:32, Nuno Oliveira
wrote:
> I don't have any voting power, just want to express my +1 towards that
> change ... a
+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 05
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 wro
+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).
Hi (apologies for the cross post),
I would like to hear opinions on changing the release procedures slightly,
and cutting the stable
branch directly on the beta release.
The reason for not doing the cut on beta but on RC originally was to push
devs to concentrate
on bug fixing.
However, since then
13 matches
Mail list logo
