RC announcements at php.net

18 years ago by Ilia Alshanetsky — view source

unread

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.

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

--

Ilia Alshanetsky

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Lukas Kahwe Smith — view source

unread

Antony Dovgal 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

18 years ago by Pierre — view source

unread

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

18 years ago by Alexey Zakhlestin — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Sebastian Nohn — view source

unread

Antony Dovgal 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

18 years ago by Derick Rethans — view source

unread

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

18 years ago by Steph Fox — view source

unread

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

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Steph Fox — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Richard Lynch — view source

unread

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.

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

--

--
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?

18 years ago by Michael Wallner — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Hannes Magnusson — view source

unread

Hi

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

18 years ago by Hannes Magnusson — view source

unread

Hi all

Hi

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

18 years ago by Steph Fox — view source

unread

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

18 years ago by Hannes Magnusson — view source

unread

Hi Steph

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 :]

Steph

-Hannes

18 years ago by Antony Dovgal — view source

unread

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:

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

--
Wbr,
Antony Dovgal

18 years ago by Hannes Magnusson — view source

unread

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"

Releases

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

--
Wbr,
Antony Dovgal

18 years ago by Antony Dovgal — view source

unread

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.

Releases

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Jochem Maas — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Jochem Maas — view source

unread

Antony Dovgal 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:

end users often push the envelope of what is possible farther than the original
developer intended.
end users' creative use of the language can lead to as yet unforeseen cases
being brought to light.
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 :-)

18 years ago by Marcus Boerger — view source

unread

Hello Antony,

Friday, February 16, 2007, 11:39:00 AM, you 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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Marcus Boerger — view source

unread

Hello Antony,

Monday, February 19, 2007, 7:12:27 PM, you 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

18 years ago by Antony Dovgal — view source

unread

Hello Antony,

Monday, February 19, 2007, 7:12:27 PM, you 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