Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56298 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88403 invoked from network); 12 Nov 2011 01:41:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Nov 2011 01:41:57 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.213.170 mail-yx0-f170.google.com Received: from [209.85.213.170] ([209.85.213.170:57586] helo=mail-yx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E7/31-15743-3EECDBE4 for ; Fri, 11 Nov 2011 20:41:56 -0500 Received: by yenm5 with SMTP id m5so4299926yen.29 for ; Fri, 11 Nov 2011 17:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=caMqptb387RsmHK4weQkH7d9oWMOQQB71lsHgDSxFDk=; b=uSWWBAoG7GphhstN6a+xGzJsaj0FJ1o3U1/Qm/BQyCUxBO7hpRMVl5fUZc8x4t805f qspZ/00iX/fpU24E4ORdqSUHGMf7OLNsIb0ZzfA5sdbhXha7aqcN9Igp8W9ciBWh4nlw +jgJ/GvnMLr+1EdVAz+Wv7yr2aEZNH+MpHL7Y= MIME-Version: 1.0 Received: by 10.147.166.17 with SMTP id t17mr348187yao.28.1321062111771; Fri, 11 Nov 2011 17:41:51 -0800 (PST) Received: by 10.146.168.7 with HTTP; Fri, 11 Nov 2011 17:41:51 -0800 (PST) In-Reply-To: References: Date: Sat, 12 Nov 2011 02:41:51 +0100 Message-ID: To: Ferenc Kovacs Cc: PHP Internals , David Soria Parra , Philip Olson , =?ISO-8859-1?Q?Johannes_Schl=FCter?= , Stanislav Malyshev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] release-qa.php and README.RELEASE_PROCESS From: pierre.php@gmail.com (Pierre Joye) 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, On Sat, Nov 12, 2011 at 12:30 AM, Ferenc Kovacs wrote: > Hi. > > I mentioned this before, and I remembered yesterday when David updated th= e > README.RELEASE_PROCESS: > http://svn.php.net/viewvc?view=3Drevision&revision=3D319009 : > 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 th= e > next qa version to be 5.3.8, but active =3D> false > http://svn.php.net/viewvc/web/qa/trunk/include/release-qa.php?r1=3D314792= &r2=3D315141 > This made the 5.3 versions disappear from the version list at bugs.php.ne= t: > 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' =3D> array( > 'active' =3D> true, > 'snaps' =3D> array( > 'prefix' =3D> 'phpX.Y-latest', > 'baseurl' =3D> 'http://snaps.php.net/', > ), > ), > > this seems to be suggested by philip also (I don't know his rationale): > http://svn.php.net/viewvc?view=3Drevision&revision=3D316012 > > 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= =3D315166&r2=3D315165&pathrev=3D315166 > ) > and update the README.RELEASE_PROCESS to reflect this (adding the upcomin= g > version as active on each stable release and not > adding/removing/inactivating it when we EOLing a branch/major.minor versi= on) > > I hope this clears up the situation. > > ps: having an api for getting the active branches would be still a cleane= r, > more straightforward solution. > that would be easy to implement ( returning an array in json from a confi= g > file). > > -- > Ferenc Kov=E1cs > @Tyr43l - http://tyrael.hu > --=20 Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org