Re: [CORE] Restore-reliability mode - Mailing list pgsql-hackers
| From | Magnus Hagander |
|---|---|
| Subject | Re: [CORE] Restore-reliability mode |
| Date | |
| Msg-id | CABUevExFm8E=+YSbYbCys67jobaY+gUAR19Mh4kMhQaVuupd0w@mail.gmail.com Whole thread Raw |
| In response to | Re: [CORE] Restore-reliability mode (Simon Riggs <simon@2ndQuadrant.com>) |
| Responses |
Re: [CORE] Restore-reliability mode
(Devrim GÜNDÜZ <devrim@gunduz.org>)
|
| List | pgsql-hackers |
On Sat, Jun 6, 2015 at 11:07 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 5 June 2015 at 17:20, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:Simon Riggs wrote:
> On 5 June 2015 at 15:00, Robert Haas <robertmhaas@gmail.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 definitionsAlpha: 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".
pgsql-hackers by date: