Re: [CORE] Restore-reliability mode

On Sat, Jun 6, 2015 at 11:07 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> On 5 June 2015 at 17:20, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
>> Simon Riggs wrote:
>> > On 5 June 2015 at 15:00, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> > > Stamping it a beta implies that we think it's something fairly
>> > > stable that we'd be pretty happy to release if things go well, which
>> > > is a higher bar to clear.
>> >
>> > We don't have a clear definition of what Beta means. For me, Beta has
>> > always meant "trial software, please test".
>>
>> I think that definition *is* the problem, actually. To me, "beta" means
>> "trial software, please test, but final product will be very similar to
>> what you see here". What we need to convey at this point is what you
>> said, but I think a better word for that is "alpha". There may be more
>> mobility in there than in a beta, in users's perception, which is the
>> right impression we want to convey.
>>
>> Another point is that historically, once we've released a beta, we're
>> pretty reluctant to bump catversion. We're not ready for that at this
>> stage, which is one criteria that suggests to me that we're not ready
>> for beta.
>>
>> So I think the right thing to do at this point is to get an alpha out,
>> shortly after releasing upcoming minors.
>>
>
> OK, I can get behind that.
>
> My only additional point is that it is a good idea to release an Alpha
> every time, not just this release.
>
> And if its called Alpha, lets release it immediately. We can allow Alpha1,
> Alpha2 as needed, plus we allow catversion and file format changes between
> Alpha versions.
>

If I'm not mistaken, we (Simon and me) actually discussed something else
along this line a while ago that might be worth considering. That is, maybe
we should consider time-based alpha releases. That is, we can just decide
"we wrap an alpha every other Monday until we think we are good to go with
beta". The reason for that is to get much quicker iteration on bugfixes,
which would encourage people to use and test these versions. Report a bug
and if it was easy enough to fix, you have a wrapped release with the fix
in 2 weeks top.

This would require that we can (at least mostly) automate the wrapping of
an alpha release, but I'm pretty sure we can solve that problem. We can
also, I think, get a way with doing the release notes for an alpha just as
a wiki page and a lot less formal than others, meaning we don't need to
hold up any process for that.

Package availability would depend on platform. For those platforms where
package building is more or less entirely automatic already, this could
probably also be easily automated. And for those that take a lot more work,
such as the Windows installers, we could just go with wrapping every other
or every third alpha. As this is not a production release, I don't see why
we'd need to hold some back to cover for the rest.

>
> Proposed definitions
>
> Alpha: This is trial software please actively test and report bugs. Your
> feedback is sought on usability and performance, which may result in
> changes to the features included here. Not all known issues have been
> resolved but work continues on resolving them. Multiple Alpha versions may
> be released before we move to Beta. We reserve the right to change internal
> API definitions, file formats and increment the catalog version between
> Alpha versions and Beta, so we do not guarantee and easy upgrade path from
> this version to later versions of this release.
>
> Beta: This is trial software please actively test and report bugs and
> performance issues. Multiple Beta versions may be released before we move
> to Release Candidate. We will attempt to maintain APIs, file formats and
> catversions.
>
>
These sound like good definitions. Might add to the beta one something like
"whilst we will try to avoid it, pg_upgrade may be required between betas
and from beta to rc versions".

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/