On Thu, 2005-10-06 at 16:57 +0200, aeb wrote:
> i propose to use 0.9.16.100 as a new branch for additional code for .16
> and stay with head as 0.9.18
I am not in favour of a new branch at all, unless it branched from HEAD
as part of an RC cycle for 18.
I will add Sigurd's patch to phpgwapi/doc/
velopers-bounces+cboettger->
> > [EMAIL PROTECTED] On Behalf Of Dave Hall
> > > Sent: Wednesday, October 05, 2005 12:12 AM
> > > To: phpgroupware-developers@gnu.org
> > > Subject: RE: [Phpgroupware-developers] Proposed changes to 16 API
> > >
> >
> >
On Thu, 2005-10-06 at 13:57 +0200, Mailings - Christian Boettger wrote:
> Hi,
>
> [Dave Hall]
>
> > With what version #?
>
> Honestly, I don't really care. A version number is just a number which we
> define. Call ist .18 (and call the HEAD based release .20) or call it .15 or
> whatever.
I
Hi,
[Dave Hall]
> With what version #?
Honestly, I don't really care. A version number is just a number which we
define. Call ist .18 (and call the HEAD based release .20) or call it .15 or
whatever.
Christian
___
Phpgroupware-developers mailing
ve Hall
> > Sent: Wednesday, October 05, 2005 12:12 AM
> > To: phpgroupware-developers@gnu.org
> > Subject: RE: [Phpgroupware-developers] Proposed changes to 16 API
> >
>
> > > I propose to build a .18 (or .20 or whatever we like to call it)
> > > v
g
> Subject: RE: [Phpgroupware-developers] Proposed changes to 16 API
>
> > I propose to build a .18 (or .20 or whatever we like to call it)
> > version, consisting of the current .16 + your additions,
> make that a
> > stable release (which should be trivial seen in the ligh
Please have a look at the XSLT-patch - and see if there is a way to include it.
(I have been patient for two years - so please give it a try)
https://savannah.gnu.org/patch/download.php?item_id=4035&item_file_id=5271
It is some changes to:
class.categories.inc.php,
class.common.inc.php,
class.ne
On Tue, 2005-10-04 at 23:23 +, Chris Weiss wrote:
> On 10/4/05, Dave Hall <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-10-04 at 11:36 -0500, Chris Weiss wrote:
> > > what about a new "app" for storing unsupported api classes? This
> > > could even be a HEAD only app and have the stable parts of
On 10/4/05, Sigurd Nes <[EMAIL PROTECTED]> wrote:
> > for this, i would support the CreateObject function to be slightly
> > mod'd to check for this api when it doens't find a requested class.
> > The error handling should already be there so it's just another if().
> >
> >
> I don't think that is
On 10/4/05, Dave Hall <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-10-04 at 11:36 -0500, Chris Weiss wrote:
> > what about a new "app" for storing unsupported api classes? This
> > could even be a HEAD only app and have the stable parts of it moved to
> > main API at release time. Afterall, these ar
What do people think? I plan to commit this in a few days
unless there is any real objections.
>>>
>>>I do strongly object putting so many new things into .16. Really. We have
>>>rejected
>>>smaller changes in the past for stability reasons.
>>>
>>>I propose to build a .18 (or .20 or what
On Tue, 2005-10-04 at 11:36 -0500, Chris Weiss wrote:
> what about a new "app" for storing unsupported api classes? This
> could even be a HEAD only app and have the stable parts of it moved to
> main API at release time. Afterall, these are 3rd party and
> unsupported apps we are talking about.
On Tue, 2005-10-04 at 13:42 +0200, Mailings - Christian Boettger wrote:
> Hi,
>
>
> > What do people think? I plan to commit this in a few days
> > unless there is any real objections.
>
> I do strongly object putting so many new things into .16. Really. We
> have rejected smaller changes in
what about a new "app" for storing unsupported api classes? This
could even be a HEAD only app and have the stable parts of it moved to
main API at release time. Afterall, these are 3rd party and
unsupported apps we are talking about.
for this, i would support the CreateObject function to be sli
> > What do people think? I plan to commit this in a few days
> > unless there is any real objections.
>
> I do strongly object putting so many new things into .16. Really. We have
> rejected
> smaller changes in the past for stability reasons.
>
> I propose to build a .18 (or .20 or whatever we
Hi,
> What do people think? I plan to commit this in a few days
> unless there is any real objections.
I do strongly object putting so many new things into .16. Really. We have
rejected smaller changes in the past for stability reasons.
I propose to build a .18 (or .20 or whatever we like
Hi all,
I know the clear policy of the project is to not include new features in
stable. At the same time I believe that duplicating the same code
multiple times in applications is a waste of time for the developer to
add, a mess of empty directories when it is moved to the API and of
little bene
17 matches
Mail list logo
