Hi.
I mentioned this before, and I remembered yesterday when David updated the
README.RELEASE_PROCESS:
http://svn.php.net/viewvc?view=revision&revision=319009 :
Currently bugs.php.net uses the qa.php.net api to decide which PHP branch
are active, so what version should be listed for the bugreports.
As we didn't have any specific api listing the active branches, I guessed
that the active branches will always have an active qa version.
This assumption failed with the release of 5.3.7 when Johannes updated the
next qa version to be 5.3.8, but active => false
http://svn.php.net/viewvc/web/qa/trunk/include/release-qa.php?r1=314792&r2=315141
This made the 5.3 versions disappear from the version list at bugs.php.net:
internals@lists.php.net/msg52793.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg52793.html
(check the thread or at least my comments)
As I mentioned there, always having an active qa release for the active
branches should fix this issue (there is no need having a release, just
having it active), something like this:
'X.Y.Z' => array(
'active' => true,
'snaps' => array(
'prefix' => 'phpX.Y-latest',
'baseurl' => 'http://snaps.php.net/',
),
),
this seems to be suggested by philip also (I don't know his rationale):
http://svn.php.net/viewvc?view=revision&revision=316012
So we can either agree on this (and then I can revert
http://svn.php.net/viewvc/web/php-bugs/trunk/include/php_versions.php?r1=315166&r2=315165&pathrev=315166
)
and update the README.RELEASE_PROCESS to reflect this (adding the upcoming
version as active on each stable release and not
adding/removing/inactivating it when we EOLing a branch/major.minor version)
I hope this clears up the situation.
ps: having an api for getting the active branches would be still a cleaner,
more straightforward solution.
that would be easy to implement ( returning an array in json from a config
file).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
we have that already as part of the rmtools. The only data missing is
the list of branches as json, which is a simple export of the list
avaible in svn. I will add it and that's it.
The rest of the info, builds errors and co (like last available
revision) are already available as json data.
Maybe it would be nice if you begin to realize that you are not alone
around here to work on that, and certainly since 2 weeks.
Cheers,
Hi.
I mentioned this before, and I remembered yesterday when David updated the
README.RELEASE_PROCESS:
http://svn.php.net/viewvc?view=revision&revision=319009 :
Currently bugs.php.net uses the qa.php.net api to decide which PHP branch
are active, so what version should be listed for the bugreports.
As we didn't have any specific api listing the active branches, I guessed
that the active branches will always have an active qa version.
This assumption failed with the release of 5.3.7 when Johannes updated the
next qa version to be 5.3.8, but active => false
http://svn.php.net/viewvc/web/qa/trunk/include/release-qa.php?r1=314792&r2=315141
This made the 5.3 versions disappear from the version list at bugs.php.net:
internals@lists.php.net/msg52793.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg52793.html
(check the thread or at least my comments)
As I mentioned there, always having an active qa release for the active
branches should fix this issue (there is no need having a release, just
having it active), something like this:
'X.Y.Z' => array(
'active' => true,
'snaps' => array(
'prefix' => 'phpX.Y-latest',
'baseurl' => 'http://snaps.php.net/',
),
),this seems to be suggested by philip also (I don't know his rationale):
http://svn.php.net/viewvc?view=revision&revision=316012So we can either agree on this (and then I can revert
http://svn.php.net/viewvc/web/php-bugs/trunk/include/php_versions.php?r1=315166&r2=315165&pathrev=315166
)
and update the README.RELEASE_PROCESS to reflect this (adding the upcoming
version as active on each stable release and not
adding/removing/inactivating it when we EOLing a branch/major.minor version)I hope this clears up the situation.
ps: having an api for getting the active branches would be still a cleaner,
more straightforward solution.
that would be easy to implement ( returning an array in json from a config
file).--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi Pierre,
This thread isn't related to ci.qa.php.net in any way, from your reply it
seems that you think it does.
Of course I could fetch the list of branches from svn, but I don't need the
list of all branches, just the supported ones, and as I said, currently
there is no way (not that I'm aware of) fetching this info programatically.
So as I said, I'm using the qa.php.net api (
http://qa.php.net/api.php?type=qa-releases&format=json&only=dev_versions)
for fetching the dev versions, but if we don't watch out for setting the
config there correctly(or making the active branches available some other
ways), then that will cause problems.
Of course we can just hard code that info to bugsweb as it was before, but
that would a step backward.
we have that already as part of the rmtools. The only data missing is
the list of branches as json, which is a simple export of the list
avaible in svn. I will add it and that's it.The rest of the info, builds errors and co (like last available
revision) are already available as json data.Maybe it would be nice if you begin to realize that you are not alone
around here to work on that, and certainly since 2 weeks.Cheers,
Hi.
I mentioned this before, and I remembered yesterday when David updated
the
README.RELEASE_PROCESS:
http://svn.php.net/viewvc?view=revision&revision=319009 :
Currently bugs.php.net uses the qa.php.net api to decide which PHP
branch
are active, so what version should be listed for the bugreports.
As we didn't have any specific api listing the active branches, I guessed
that the active branches will always have an active qa version.
This assumption failed with the release of 5.3.7 when Johannes updated
the
next qa version to be 5.3.8, but active => falsehttp://svn.php.net/viewvc/web/qa/trunk/include/release-qa.php?r1=314792&r2=315141
This made the 5.3 versions disappear from the version list at
bugs.php.net:
internals@lists.php.net/msg52793.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg52793.html
(check the thread or at least my comments)
As I mentioned there, always having an active qa release for the active
branches should fix this issue (there is no need having a release, just
having it active), something like this:
'X.Y.Z' => array(
'active' => true,
'snaps' => array(
'prefix' => 'phpX.Y-latest',
'baseurl' => 'http://snaps.php.net/',
),
),this seems to be suggested by philip also (I don't know his rationale):
http://svn.php.net/viewvc?view=revision&revision=316012So we can either agree on this (and then I can revert
)
and update the README.RELEASE_PROCESS to reflect this (adding the
upcoming
version as active on each stable release and not
adding/removing/inactivating it when we EOLing a branch/major.minor
version)I hope this clears up the situation.
ps: having an api for getting the active branches would be still a
cleaner,
more straightforward solution.
that would be easy to implement ( returning an array in json from a
config
file).--
Ferenc Kovács
@Tyr43l - http://tyrael.hu--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi.
I mentioned this before, and I remembered yesterday when David updated the
README.RELEASE_PROCESS:
http://svn.php.net/viewvc?view=revision&revision=319009 :
Currently bugs.php.net uses the qa.php.net api to decide which PHP branch
are active, so what version should be listed for the bugreports.
As we didn't have any specific api listing the active branches, I guessed
that the active branches will always have an active qa version.
This assumption failed with the release of 5.3.7 when Johannes updated the
next qa version to be 5.3.8, but active => falsehttp://svn.php.net/viewvc/web/qa/trunk/include/release-qa.php?r1=314792&r2=315141
This made the 5.3 versions disappear from the version list at bugs.php.net
:
internals@lists.php.net/msg52793.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg52793.html
(check the thread or at least my comments)
As I mentioned there, always having an active qa release for the active
branches should fix this issue (there is no need having a release, just
having it active), something like this:
'X.Y.Z' => array(
'active' => true,
'snaps' => array(
'prefix' => 'phpX.Y-latest',
'baseurl' => 'http://snaps.php.net/',
),
),this seems to be suggested by philip also (I don't know his rationale):
http://svn.php.net/viewvc?view=revision&revision=316012So we can either agree on this (and then I can revert
http://svn.php.net/viewvc/web/php-bugs/trunk/include/php_versions.php?r1=315166&r2=315165&pathrev=315166 )
and update the README.RELEASE_PROCESS to reflect this (adding the upcoming
version as active on each stable release and not
adding/removing/inactivating it when we EOLing a branch/major.minor version)I hope this clears up the situation.
ps: having an api for getting the active branches would be still a
cleaner, more straightforward solution.
that would be easy to implement ( returning an array in json from a config
file).--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
bump
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu