RC announcements at php.net

Ilia A.

19 years ago

I think it makes sense for RC1 and few of the first level releases
but not the very closely spaces RC4+ where there are virtually no
changes between the releases.


On 15-Feb-07, at 9:38 AM, Antony Dovgal wrote:

> Hello all.
>
> Now that the conference ads are gone, I think we should add release
> candidates announcements to the first page of php.net.
> This will add some more attention to the RCs and (I hope) will help
> users to help us in making the releases more stable.
> Any objections? I hope none.
>
> --
> Wbr, Antony Dovgal
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Ilia Alshanetsky

Antony Dovgal

19 years ago

On 02/15/2007 06:24 PM, Ilia Alshanetsky wrote:

> I think it makes sense for RC1 and few of the first level releases
> but not the very closely spaces RC4+ where there are virtually no
> changes between the releases.

I believe it doesn't matter which RC is that, it helps to detect problems on the early stage anyway.
I wouldn't like to miss a bug just because someone missed an RC announcement.

--
Wbr,
Antony Dovgal

Lukas Kahwe Smith

19 years ago

Antony Dovgal wrote:

> On 02/15/2007 06:24 PM, Ilia Alshanetsky wrote:
>> I think it makes sense for RC1 and few of the first level releases
>> but not the very closely spaces RC4+ where there are virtually no
>> changes between the releases.
>
> I believe it doesn't matter which RC is that, it helps to detect
> problems on the early stage anyway.
> I wouldn't like to miss a bug just because someone missed an RC
> announcement.

Also it will be too untransparent for users what RC's get published and
which dont ..

Whatever the decision please add it to the release check list on the wiki :)

regards,
Lukas

Pierre Joye

19 years ago

On 2/15/07, Antony Dovgal <antony@zend.com> wrote:

> On 02/15/2007 06:24 PM, Ilia Alshanetsky wrote:
> > I think it makes sense for RC1 and few of the first level releases
> > but not the very closely spaces RC4+ where there are virtually no
> > changes between the releases.
>
> I believe it doesn't matter which RC is that, it helps to detect problems on the early stage anyway.
> I wouldn't like to miss a bug just because someone missed an RC announcement.

I agree. All releases should be announced. I can imagine a little
image to tell when a release announcement is QA (RC) release or the
final release. I'm not sure it will help to get more testers or
feedbacks, but it costs nothing to do it :)

--Pierre

Alexey Zakhlestin

19 years ago

probably, here should be a block on the main page:

Latest testing release: X.X.XRC1 (changelog)
Latest stable release: X.X.X (changelog)

and "testing release" should just disappear when there are no release
candidates available

Antony Dovgal

19 years ago

On 02/15/2007 06:49 PM, Alexey Zakhlestin wrote:

> probably, here should be a block on the main page:
>
> Latest testing release: X.X.XRC1 (changelog)
> Latest stable release: X.X.X (changelog)
>
> and "testing release" should just disappear when there are no release
> candidates available

Yeah, I would mind if we merge this part of qa.php.net into php.net.
It's just a small block, but it would help us to gain a lot of feedback.

--
Wbr,
Antony Dovgal

Sebastian Nohn

19 years ago

Antony Dovgal wrote:

> On 02/15/2007 06:49 PM, Alexey Zakhlestin wrote:
>> probably, here should be a block on the main page:
>>
>> Latest testing release: X.X.XRC1 (changelog)
>> Latest stable release: X.X.X (changelog)
>>
>> and "testing release" should just disappear when there are no release
>> candidates available
>
> Yeah, I would mind if we merge this part of qa.php.net into php.net.
> It's just a small block, but it would help us to gain a lot of feedback.

Wouldn't it make sense to make the "Providing QA for PHP"... block
available as RSS at the same time?

- Sebastian

Derick Rethans

19 years ago

On Thu, 15 Feb 2007, Alexey Zakhlestin wrote:

> probably, here should be a block on the main page:
>
> Latest testing release: X.X.XRC1 (changelog)
> Latest stable release: X.X.X (changelog)
>
> and "testing release" should just disappear when there are no release
> candidates available

That sounds like a good plan as well!

regards,
Derick

Steph

19 years ago

Hi Tony,

We've been here before. Last time it got taken off again because it led to
user confusion. People didn't seem to know the difference between a release
candidate and a full release; "It was official, it was on php.net."

Please can it be made VERY clear, both in the announcements and on the
download page (qa.php.net?) that RC's are for test purposes only?

Cheers,

- Steph

----- Original Message -----
From: "Antony Dovgal" <antony@zend.com>
To: "php-dev" <internals@lists.php.net>
Sent: Thursday, February 15, 2007 2:38 PM
Subject: [PHP-DEV] RC announcements at php.net

Antony Dovgal

19 years ago

On 02/15/2007 07:22 PM, Steph Fox wrote:

> Hi Tony,
>
> We've been here before. Last time it got taken off again because it led to
> user confusion. People didn't seem to know the difference between a release
> candidate and a full release; "It was official, it was on php.net."

.. it was explained that it's not a release, but a release candidate.
?

> Please can it be made VERY clear, both in the announcements and on the
> download page (qa.php.net?) that RC's are for test purposes only?

That depends on the wording and I hope you'll help us to find the best one, as a native speaker =)

--
Wbr,
Antony Dovgal

Steph

19 years ago

> On 02/15/2007 07:22 PM, Steph Fox wrote:
>> Hi Tony,
>>
>> We've been here before. Last time it got taken off again because it led
>> to user confusion. People didn't seem to know the difference between a
>> release candidate and a full release; "It was official, it was on
>> php.net."
>
> .. it was explained that it's not a release, but a release candidate.
> ?

I know that, you know that, but thousands don't know what a release
candidate even is :)

>> Please can it be made VERY clear, both in the announcements and on the
>> download page (qa.php.net?) that RC's are for test purposes only?
>
> That depends on the wording and I hope you'll help us to find the best
> one, as a native speaker =)

Sure. Ping me.

- Steph

Antony Dovgal

19 years ago

On 02/15/2007 07:42 PM, Steph Fox wrote:

>> On 02/15/2007 07:22 PM, Steph Fox wrote:
>>> Hi Tony,
>>>
>>> We've been here before. Last time it got taken off again because it led
>>> to user confusion. People didn't seem to know the difference between a
>>> release candidate and a full release; "It was official, it was on
>>> php.net."
>>
>> .. it was explained that it's not a release, but a release candidate.
>> ?
>
> I know that, you know that, but thousands don't know what a release
> candidate even is :)

Then we should describe the difference as clear as we can.

>>> Please can it be made VERY clear, both in the announcements and on the
>>> download page (qa.php.net?) that RC's are for test purposes only?
>>
>> That depends on the wording and I hope you'll help us to find the best
>> one, as a native speaker =)

Thanks in advance =)

--
Wbr,
Antony Dovgal

Richard Lynch

19 years ago

I'm +1 on the separate block.

SUGGESTIONS:

Put the STABLE RELEASE link *before* any RC release.
Rationale: Users in a hurry will more likely click the first one.

Add an EXTRA page in between the homepage and download of RC saying
something not unlike:
You are downloading a RELEASE CANDIDATE.
This should be used for TEST PURPOSES ONLY.
Make the user read that and click an extra button/step.
Yes, it is slightly more inconvenient, and that's a Good Thing

Instead of "RELEASE CANDIDATE" just call it "UNSTABLE" or "TEST"
branch in the text of the link.

On Thu, February 15, 2007 10:42 am, Steph Fox wrote:

>> On 02/15/2007 07:22 PM, Steph Fox wrote:
>>> Hi Tony,
>>>
>>> We've been here before. Last time it got taken off again because it
>>> led
>>> to user confusion. People didn't seem to know the difference
>>> between a
>>> release candidate and a full release; "It was official, it was on
>>> php.net."
>>
>> .. it was explained that it's not a release, but a release
>> candidate.
>> ?
>
> I know that, you know that, but thousands don't know what a release
> candidate even is :)
>
>>> Please can it be made VERY clear, both in the announcements and on
>>> the
>>> download page (qa.php.net?) that RC's are for test purposes only?
>>
>> That depends on the wording and I hope you'll help us to find the
>> best
>> one, as a native speaker =)
>
> Sure. Ping me.
>
> - Steph
>
>>
>> --
>> Wbr, Antony Dovgal
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Michael Wallner

19 years ago

Antony Dovgal wrote:

> Now that the conference ads are gone, I think we should add release
> candidates announcements to the first page of php.net.

> Any objections? I hope none.

I actually think this is a pretty good idea, and thanks to Hannes for the cleanup.

--
Michael

Antony Dovgal

19 years ago

On 02/15/2007 05:38 PM, Antony Dovgal wrote:

> Hello all.
>
> Now that the conference ads are gone, I think we should add release candidates announcements to the first page of php.net.
> This will add some more attention to the RCs and (I hope) will help users to help us in making the releases more stable.
> Any objections? I hope none.
>

Just to quote Greg here:

<CelloG> you could solve Steph's concern by putting the "testing release" block in a different place
<CelloG> put the official current release block in the upper left
<CelloG> and the testing block down on the left a little lower

This sounds like the way to go.

We also can add a detailed description of what is release candidate, what's the difference comparing to a release etc. to qa.php.net
and add a link to that page in the block. Actually, I'll try to write something tomorrow.

Any more volunteers to patch php.net?
Hannes? You seem to be the most active person in that area atm =)

--
Wbr,
Antony Dovgal

Hannes Magnusson

19 years ago

Hi

On 2/15/07, Antony Dovgal <antony@zend.com> wrote:

> On 02/15/2007 05:38 PM, Antony Dovgal wrote:
> > Hello all.
> >
> > Now that the conference ads are gone, I think we should add release candidates announcements to the first page of php.net.
> > This will add some more attention to the RCs and (I hope) will help users to help us in making the releases more stable.
> > Any objections? I hope none.
> >
>
> Just to quote Greg here:
>
> <CelloG> you could solve Steph's concern by putting the "testing release" block in a different place
> <CelloG> put the official current release block in the upper left
> <CelloG> and the testing block down on the left a little lower
>
> This sounds like the way to go.
>
> We also can add a detailed description of what is release candidate, what's the difference comparing to a release etc. to qa.php.net
> and add a link to that page in the block. Actually, I'll try to write something tomorrow.
>
> Any more volunteers to patch php.net?
> Hannes? You seem to be the most active person in that area atm =)

As I am all for the idea I will definitely prepare a patch

-Hannes

Hannes Magnusson

19 years ago

Hi all

On 2/15/07, Hannes Magnusson <bjori@php.net> wrote:

> Hi
>
> On 2/15/07, Antony Dovgal <antony@zend.com> wrote:
> > On 02/15/2007 05:38 PM, Antony Dovgal wrote:
> > > Hello all.
> > >
> > > Now that the conference ads are gone, I think we should add release candidates announcements to the first page of php.net.
> > > This will add some more attention to the RCs and (I hope) will help users to help us in making the releases more stable.
> > > Any objections? I hope none.
> > >
> >
> > Just to quote Greg here:
> >
> > <CelloG> you could solve Steph's concern by putting the "testing release" block in a different place
> > <CelloG> put the official current release block in the upper left
> > <CelloG> and the testing block down on the left a little lower
> >
> > This sounds like the way to go.
> >
> > We also can add a detailed description of what is release candidate, what's the difference comparing to a release etc. to qa.php.net
> > and add a link to that page in the block. Actually, I'll try to write something tomorrow.
> >
> > Any more volunteers to patch php.net?
> > Hannes? You seem to be the most active person in that area atm =)
>
> As I am all for the idea I will definitely prepare a patch
>
> -Hannes
>

So, here is my left handed pet dwarf turtle, born in December, idea:
It doesn't really see the point of scattering boxes all around. One
box listing current php5 + php4 version and the current release
candidates should be all that we need.
The RC links obviously won't be direct links on the tarballs so the
user still has a chance of understanding "wth is RC?".

The release candidate links will point to qa.php.net/#v5 & #v4 where
we'll add a big fat box explaining the concept of release _candidate_.
The stable links then point to php.net/downloads.php#v5 & #v4

The only "major" change is how RM will post a new release; this patch
expects all current (stable and (if any) rc) in include/version.inc

See attached, simplified, patch & screenshot:
http://home.oslo.nith.no/~maghan/releases.png

We can then provide a Atom+SLE feed with latest versions with direct
links to the stable releases and a link to qa.php.net with RCs....


If I am totally off base here, scream :)

-Hannes

Steph

19 years ago

Hi Hannes,

> So, here is my left handed pet dwarf turtle, born in December, idea:
> It doesn't really see the point of scattering boxes all around. One
> box listing current php5 + php4 version and the current release
> candidates should be all that we need.
> The RC links obviously won't be direct links on the tarballs so the
> user still has a chance of understanding "wth is RC?".
>
> The release candidate links will point to qa.php.net/#v5 & #v4 where
> we'll add a big fat box explaining the concept of release _candidate_.
> The stable links then point to php.net/downloads.php#v5 & #v4
>
> The only "major" change is how RM will post a new release; this patch
> expects all current (stable and (if any) rc) in include/version.inc
>
> See attached, simplified, patch & screenshot:
> http://home.oslo.nith.no/~maghan/releases.png
>
> We can then provide a Atom+SLE feed with latest versions with direct
> links to the stable releases and a link to qa.php.net with RCs....
>
>
> If I am totally off base here, scream :)

My right handed pet killer rabbit, born in July, quite likes it :) but
noticed that you didn't make that conference/cfp block at the top happen
yet...?

- Steph

>
> -Hannes
>

--------------------------------------------------------------------------------

Hannes Magnusson

19 years ago

Hi Steph

On 2/16/07, Steph Fox <steph@zend.com> wrote:

> Hi Hannes,
>
> > So, here is my left handed pet dwarf turtle, born in December, idea:
> > It doesn't really see the point of scattering boxes all around. One
> > box listing current php5 + php4 version and the current release
> > candidates should be all that we need.
> > The RC links obviously won't be direct links on the tarballs so the
> > user still has a chance of understanding "wth is RC?".
> >
> > The release candidate links will point to qa.php.net/#v5 & #v4 where
> > we'll add a big fat box explaining the concept of release _candidate_.
> > The stable links then point to php.net/downloads.php#v5 & #v4
> >
> > The only "major" change is how RM will post a new release; this patch
> > expects all current (stable and (if any) rc) in include/version.inc
> >
> > See attached, simplified, patch & screenshot:
> > http://home.oslo.nith.no/~maghan/releases.png
> >
> > We can then provide a Atom+SLE feed with latest versions with direct
> > links to the stable releases and a link to qa.php.net with RCs....
> >
> >
> > If I am totally off base here, scream :)
>
> My right handed pet killer rabbit, born in July, quite likes it :) but
> noticed that you didn't make that conference/cfp block at the top happen
> yet...?

Hmh. Yes. Sean asked me to wait for couple of more days to see if he
can come up with something better.

The patch is actually really dirty because of our weirdo news system.
I'm kicking around the idea of replacing it with a Atom feed as
primary format which will make parsing into other formats way easier
(have you guys seen our rss feed? lol).. but that headache belongs to
another thread :]

Antony Dovgal

19 years ago

On 02/16/2007 01:00 PM, Hannes Magnusson wrote:

> So, here is my left handed pet dwarf turtle, born in December, idea:
>  It doesn't really see the point of scattering boxes all around. One
> box listing current php5 + php4 version and the current release
> candidates should be all that we need.
> The RC links obviously won't be direct links on the tarballs so the
> user still has a chance of understanding "wth is RC?".
>
> The release candidate links will point to qa.php.net/#v5 & #v4 where
> we'll add a big fat box explaining the concept of release _candidate_.
> The stable links then point to php.net/downloads.php#v5 & #v4
>
> The only "major" change is how RM will post a new release; this patch
> expects all current (stable and (if any) rc) in include/version.inc
>
> See attached, simplified, patch & screenshot:
> http://home.oslo.nith.no/~maghan/releases.png

Looks great, but I would like to divide it into two parts:
1) Releases
2) Release Candidates (which would disappear when there are no RCs).

--
Wbr,
Antony Dovgal

Hannes Magnusson

19 years ago

On 2/16/07, Antony Dovgal <antony@zend.com> wrote:

> On 02/16/2007 01:00 PM, Hannes Magnusson wrote:
> > So, here is my left handed pet dwarf turtle, born in December, idea:
> >  It doesn't really see the point of scattering boxes all around. One
> > box listing current php5 + php4 version and the current release
> > candidates should be all that we need.
> > The RC links obviously won't be direct links on the tarballs so the
> > user still has a chance of understanding "wth is RC?".
> >
> > The release candidate links will point to qa.php.net/#v5 & #v4 where
> > we'll add a big fat box explaining the concept of release _candidate_.
> > The stable links then point to php.net/downloads.php#v5 & #v4
> >
> > The only "major" change is how RM will post a new release; this patch
> > expects all current (stable and (if any) rc) in include/version.inc
> >
> > See attached, simplified, patch & screenshot:
> > http://home.oslo.nith.no/~maghan/releases.png
>
> Looks great, but I would like to divide it into two parts:

define "parts"

> 1) Releases
> 2) Release Candidates (which would disappear when there are no RCs).

Comment out the "5.2.2RC1" array in include/version.inc, tata, the
5.2.2RC "announcement" is gone...
(http://home.oslo.nith.no/~maghan/releases-no-rc.png with both php4&5
rc's commented out)

-Hannes

Antony Dovgal

19 years ago

On 02/16/2007 01:29 PM, Hannes Magnusson wrote:

>> > See attached, simplified, patch & screenshot:
>> > http://home.oslo.nith.no/~maghan/releases.png
>>
>> Looks great, but I would like to divide it into two parts:
>
> define "parts"

Just create a similar square with "Release Candidates" title and move RCs there.
That is to separate releases from release candidates and to emphasize the difference between them.

>> 1) Releases
>> 2) Release Candidates (which would disappear when there are no RCs).
>
> Comment out the "5.2.2RC1" array in include/version.inc, tata, the
> 5.2.2RC "announcement" is gone...
> (http://home.oslo.nith.no/~maghan/releases-no-rc.png with both php4&5
> rc's commented out)

That's exactly what I meant =)

--
Wbr,
Antony Dovgal

Antony Dovgal

19 years ago

On 02/16/2007 01:21 AM, Antony Dovgal wrote:

> We also can add a detailed description of what is release candidate, what's the difference comparing to a release etc. to qa.php.net
> and add a link to that page in the block. Actually, I'll try to write something tomorrow.

Please comment and correct (if needed).

Release Candidates
------------------

Release candidates are development packages released to check if any critical
problems have slipped into the code during the previous development period.
Release candidates are NOT for production use, they are for testing purposes only
even though in most cases there are (almost) no differences between the general
availability (GA) release and the last RC.
You can help us detect problems by installing and testing release candidates
on your own (non-production!) server.

Installation problems.
First of all, make sure the build process (on *nix only) and installation went fine for you.
PHP supports quite a number of operating systems on different platforms and we continue
to work on increasing this number.
Although, you might encounter some problems during the installation and we would
like to know about them.

Test engine.
When done with the build, please run the test engine by using the 'make test' command
and send us the results (hit 'Y' when it asks you whether to send the report).
This way we'll receive the required information about your system to fix the problems
detected by the test suite (if any).

Real-life tests.
We would also appreciate if you install the RC on your development server and run
your software. This would help us to detect any (unintentional) changes between
the release candidates and general releases.
Such real-life tests are the most valuable because our test suite obviously cannot
cover every possible use case (but we're working on that).

--
Wbr,
Antony Dovgal

Jochem Maas

19 years ago

Antony Dovgal wrote:

> On 02/16/2007 01:21 AM, Antony Dovgal wrote:
>> We also can add a detailed description of what is release candidate,
>> what's the difference comparing to a release etc. to qa.php.net and
>> add a link to that page in the block. Actually, I'll try to write
>> something tomorrow.
>
> Please comment and correct (if needed).

I offer a few small ideas/comments below - I hope they are not considered out of place.

>
> Release Candidates
> ------------------
>
> Release candidates are development packages released to check if any
> critical
> problems have slipped into the code during the previous development period.
> Release candidates are NOT for production use,

I would make the whole sentence above ALL CAPS. you might also consider correlating
the concept of 'UNSTABLE' with that of 'Release Candidate' given that 'UNSTABLE' is
often used in other projects and is widely, implicitly understood to mean 'not for
production use'.

> they are for testing
> purposes only even though in most cases there are (almost) no
> differences between the general
> availability (GA) release and the last RC.
> You can help us detect problems by installing and testing release
> candidates
> on your own (non-production!) server.
>
> Installation problems.
> First of all, make sure the build process (on *nix only) and
> installation went fine for you.
> PHP supports quite a number of operating systems on different platforms
> and we continue
> to work on increasing this number.
> Although, you might encounter some problems during the installation and

I would replace 'Although, you might encounter' with 'If you encounter'

> we would
> like to know about them.
>
> Test engine.

the header 'Test Engine' might not be understood and/or frighten off beginners
(whilst doing the tests is actually very easy).

you might encourage more people to run the test engine if you named the header
for this section something like one of the following:

Test Your New Installation.
Check your Installation with the Integrated Test Suite.

> When done with the build, please run the test engine by using the 'make
> test' command
> and send us the results (hit 'Y' when it asks you whether to send the
> report).
> This way we'll receive the required information about your system to fix
> the problems
> detected by the test suite (if any).

you may wish to stress how valuable this information is to you and how much
you appreciate that people send them.

>
> Real-life tests.
> We would also appreciate if you install the RC on your development
> server and run
> your software. This would help us to detect any (unintentional) changes
> between
> the release candidates and general releases.
> Such real-life tests are the most valuable because our test suite
> obviously cannot

I would remove 'obviously' and change 'cannot' with 'does not yet',
this would invoke more of a feeling of 'being in good [dev] hands' ...
which I feel is not completely out of place :-)

> cover every possible use case (but we're working on that).
>

kind regards,
Jochem

Antony Dovgal

19 years ago

On 02/16/2007 04:00 PM, Jochem Maas wrote:

> I would make the whole sentence above ALL CAPS

This text should appear at qa.php.net, so no need for CAPS (which are difficult to read),
we can just use <b></b>.

>> Although, you might encounter some problems during the installation and
>
> I would replace 'Although, you might encounter' with 'If you encounter'

Agree.

>> Test engine.
>
> the header 'Test Engine' might not be understood and/or frighten off beginners
> (whilst doing the tests is actually very easy).
>
> you might encourage more people to run the test engine if you named the header
> for this section something like one of the following:
>
> Test Your New Installation.
> Check your Installation with the Integrated Test Suite.

Agree.

> you may wish to stress how valuable this information is to you and how much
> you appreciate that people send them.

Any certain suggestions?
Somehow I've lost the inspiration I had in the morning =)

> I would remove 'obviously' and change 'cannot' with 'does not yet',
> this would invoke more of a feeling of 'being in good [dev] hands' ...
> which I feel is not completely out of place :-)

The point is that any real-life test is better than a test suite,
because a test suite will never cover everything.
But I do agree with the wording, yes.

--
Wbr,
Antony Dovgal

Jochem Maas

19 years ago

Antony Dovgal wrote:

> On 02/16/2007 04:00 PM, Jochem Maas wrote:
>> I would make the whole sentence above ALL CAPS
>
> This text should appear at qa.php.net, so no need for CAPS (which are
> difficult to read), we can just use <b></b>.

indeed - I was merely stressing that you probably cannot highlight the fact
that RCs concern non-production code enough :-) bold is just as good if not better
than all-caps.

>
>>> Although, you might encounter some problems during the installation and
>>
>> I would replace 'Although, you might encounter' with 'If you encounter'
>
> Agree.
>
>>> Test engine.
>>
>> the header 'Test Engine' might not be understood and/or frighten off
>> beginners
>> (whilst doing the tests is actually very easy).
>>
>> you might encourage more people to run the test engine if you named
>> the header
>> for this section something like one of the following:
>>
>> Test Your New Installation.
>> Check your Installation with the Integrated Test Suite.
>
> Agree.
>
>> you may wish to stress how valuable this information is to you and how
>> much
>> you appreciate that people send them.
>
> Any certain suggestions?
> Somehow I've lost the inspiration I had in the morning =)

something like this?:

the php group would like to thank you in advance for taking the time to
perform and send us the results of the test suite.

AND/OR

Each and every report goes towards helping us provide the best software we can,
your feedback is a valuable resource and the PHP group would hereby like to extend
their gratitude for your effort.

>
>> I would remove 'obviously' and change 'cannot' with 'does not yet',
>> this would invoke more of a feeling of 'being in good [dev] hands' ...
>> which I feel is not completely out of place :-)
>
> The point is that any real-life test is better than a test suite,
> because a test suite will never cover everything.

indeed - nothing like real world apps to really push php to it's limits -
no doubt that your average php'er sometimes does such crazy things that an
experienced dev would often not even imagine doing such things :-)

> But I do agree with the wording, yes.

maybe something like this:

Currently the test suite does not completely cover all code in the php software
(this is something we are working on!), regardless of this fact it is our experience
that testing pre-release versions of php against real-world [php] software - this is
due to a number of reasons:

1. end users often push the envelope of what is possible farther than the original
developer intended.
2. end users' creative use of the language can lead to as yet unforeseen cases
being brought to light.
3. real-world software environments are highly diverse, custom/exotic configurations
sometimes bring problems to light that developers often have no way of pre-empting.

we therefore kind request that you try out your own software with RC versions of php and
report any problems to bug.php.net, issues that you bring to light will help to improve
php itself and often your discoveries will lead to improvements in the test suite as well.

we would like to make a special appeal to developers of large/successful (e.g. phpMyAdmin)
php projects to test against pre-release versions, your input is of great importance due to
the highly visible nature of your application and the large users bases they support. the PHP
group recognizes the importance of large/successful [php] software projects in continuing/promoting
the success of the [php] language - your success is important to us, please help us in our
mission to provide as high quality platform as possible for your software!

the PHP group extends their gratitude to everyone who offers up their valuable time to
help with the testing effort.

>

... just some thoughts :-)

Marcus Börger

19 years ago

Hello Antony,

Friday, February 16, 2007, 11:39:00 AM, you wrote:

> On 02/16/2007 01:21 AM, Antony Dovgal wrote:
>> We also can add a detailed description of what is release candidate, what's the difference comparing to a release etc. to qa.php.net
>> and add a link to that page in the block. Actually, I'll try to write something tomorrow.

> Please comment and correct (if needed).

> Release Candidates
> ------------------

> Release candidates are development packages released to check if any critical
> problems have slipped into the code during the previous development period.
> Release candidates are NOT for production use, they are for testing purposes only
> even though in most cases there are (almost) no differences between the general
> availability (GA) release and the last RC.
> You can help us detect problems by installing and testing release candidates
> on your own (non-production!) server.

This should read: You can help yourself...

> Installation problems.
> First of all, make sure the build process (on *nix only) and installation went fine for you.
> PHP supports quite a number of operating systems on different platforms and we continue
> to work on increasing this number.
> Although, you might encounter some problems during the installation and we would
> like to know about them.

> Test engine.
> When done with the build, please run the test engine by using the 'make test' command
> and send us the results (hit 'Y' when it asks you whether to send the report).
> This way we'll receive the required information about your system to fix the problems
> detected by the test suite (if any).

> Real-life tests.
> We would also appreciate if you install the RC on your development server and run
> your software. This would help us to detect any (unintentional) changes between
> the release candidates and general releases.
> Such real-life tests are the most valuable because our test suite obviously cannot
> cover every possible use case (but we're working on that).

> --
> Wbr,
> Antony Dovgal

Best regards,
Marcus

Antony Dovgal

19 years ago

On 02/19/2007 08:40 PM, Marcus Boerger wrote:

>> Release candidates are development packages released to check if any critical
>> problems have slipped into the code during the previous development period.
>> Release candidates are NOT for production use, they are for testing purposes only
>> even though in most cases there are (almost) no differences between the general
>> availability (GA) release and the last RC.
>> You can help us detect problems by installing and testing release candidates
>> on your own (non-production!) server.
>
> This should read: You can help yourself...

I believe running the test engine and providing us with feedback users help _us_ in the first place.

>> Installation problems.
>> First of all, make sure the build process (on *nix only) and installation went fine for you.
>> PHP supports quite a number of operating systems on different platforms and we continue
>> to work on increasing this number.
>> Although, you might encounter some problems during the installation and we would
>> like to know about them.
>
>> Test engine.
>> When done with the build, please run the test engine by using the 'make test' command
>> and send us the results (hit 'Y' when it asks you whether to send the report).
>> This way we'll receive the required information about your system to fix the problems
>> detected by the test suite (if any).
>
>> Real-life tests.
>> We would also appreciate if you install the RC on your development server and run
>> your software. This would help us to detect any (unintentional) changes between
>> the release candidates and general releases.
>> Such real-life tests are the most valuable because our test suite obviously cannot
>> cover every possible use case (but we're working on that).

--
Wbr,
Antony Dovgal

Marcus Börger

19 years ago

Hello Antony,

Monday, February 19, 2007, 7:12:27 PM, you wrote:

> On 02/19/2007 08:40 PM, Marcus Boerger wrote:
>>> Release candidates are development packages released to check if any critical
>>> problems have slipped into the code during the previous development period.
>>> Release candidates are NOT for production use, they are for testing purposes only
>>> even though in most cases there are (almost) no differences between the general
>>> availability (GA) release and the last RC.
>>> You can help us detect problems by installing and testing release candidates
>>> on your own (non-production!) server.
>>
>> This should read: You can help yourself...

> I believe running the test engine and providing us with feedback users help _us_ in the first place.

If they only help us they wouldn't do anything. So we need to make clear
that they help themselves by running the tests and their own software.

>>> Installation problems.
>>> First of all, make sure the build process (on *nix only) and installation went fine for you.
>>> PHP supports quite a number of operating systems on different platforms and we continue
>>> to work on increasing this number.
>>> Although, you might encounter some problems during the installation and we would
>>> like to know about them.
>>
>>> Test engine.
>>> When done with the build, please run the test engine by using the 'make test' command
>>> and send us the results (hit 'Y' when it asks you whether to send the report).
>>> This way we'll receive the required information about your system to fix the problems
>>> detected by the test suite (if any).
>>
>>> Real-life tests.
>>> We would also appreciate if you install the RC on your development server and run
>>> your software. This would help us to detect any (unintentional) changes between
>>> the release candidates and general releases.
>>> Such real-life tests are the most valuable because our test suite obviously cannot
>>> cover every possible use case (but we're working on that).

> --
> Wbr,
> Antony Dovgal

Best regards,
Marcus

Antony Dovgal

19 years ago

On 02/19/2007 10:01 PM, Marcus Boerger wrote:

> Hello Antony,
>
> Monday, February 19, 2007, 7:12:27 PM, you wrote:
>
>> On 02/19/2007 08:40 PM, Marcus Boerger wrote:
>>>> Release candidates are development packages released to check if any critical
>>>> problems have slipped into the code during the previous development period.
>>>> Release candidates are NOT for production use, they are for testing purposes only
>>>> even though in most cases there are (almost) no differences between the general
>>>> availability (GA) release and the last RC.
>>>> You can help us detect problems by installing and testing release candidates
>>>> on your own (non-production!) server.
>>>
>>> This should read: You can help yourself...
>
>> I believe running the test engine and providing us with feedback users help _us_ in the first place.
>
> If they only help us they wouldn't do anything. So we need to make clear
> that they help themselves by running the tests and their own software.

Well, saying that they help only themselves is not true.

--
Wbr,
Antony Dovgal

Mike Robinson

19 years ago

Antony Dovgal write:

> > On 02/19/2007 08:40 PM, Marcus Boerger wrote:
> > If they only help us they wouldn't do anything. So we need to make
> > clear that they help themselves by running the tests and
> their own software.
>
> Well, saying that they help only themselves is not true.

"You can help yourself and the PHP team detect problems by installing..."

I'd say that was more accurate and more likely to inspire people to
contribute.

Best,

Mike Robinson

Antony Dovgal

19 years ago

On 02/20/2007 03:15 AM, Mike R wrote:

> Antony Dovgal write:
>> > On 02/19/2007 08:40 PM, Marcus Boerger wrote:
>> > If they only help us they wouldn't do anything. So we need to make
>> > clear that they help themselves by running the tests and
>> their own software.
>>
>> Well, saying that they help only themselves is not true.
>
> "You can help yourself and the PHP team detect problems by installing..."
>
> I'd say that was more accurate and more likely to inspire people to
> contribute.

I'd reorder it like this:
"You can help the PHP team and yourself detect problems by installing..."

Ok, here is the final version.

==============================================
Release Candidates
------------------

Release candidates are development packages released to check if any critical
problems have slipped into the code during the previous development period.
Release candidates are NOT for production use, they are for testing purposes only
even though in most cases there are (almost) no differences between the general
availability (GA) release and the last RC.
You can help the PHP Team and yourself detect problems by installing and testing
release candidates on your own (non-production!) server.

Installation problems.
First of all, make sure the build process (on *nix only) and installation went fine for you.
PHP supports quite a number of operating systems on different platforms and we continue
to work on increasing this number.
If you encounter any problems during the installation, we would like to know about them.

Testing the installation.
When done with the build, please run the test engine by using the 'make test' command
and send us the results (hit 'Y' when it asks you whether to send the report).
This way we'll receive the required information about your system to fix the problems
detected by the test suite (if any). Each and every report goes towards helping us
provide the best software we can, your feedback is a valuable resource and the
PHP group would hereby like to extend their gratitude for your effort.

Real-life tests.
We would also appreciate if you install the RC on your development server and run
your software. This would help us to detect any (unintentional) changes between
the release candidates and general releases.
Such real-life tests are the most valuable because our test suite does not yet
cover every possible use case (but we're working on that).
==============================================

--
Wbr,
Antony Dovgal