[Andi Gutmans [EMAIL PROTECTED]]
At 12:01 PM 9/26/2001 -0400, Joao Prado Maia wrote:
On Wed, 26 Sep 2001, Andi Gutmans wrote:
I think the key still lies in creating a repository for C extensions where
each extension can have its own release cycle.
That is also true, but we still
At 12:52 27-09-01, Stig Sæther Bakken wrote:
Yes, definitely.
But what do you think about the versioning scheme Jani proposed?
-1 from me on it the way it is, I don't think that bumping the middle digit
for every functionality change is a good idea.
Bug-fixes and new functionality is
At 09:12 PM 9/25/2001 +0200, Stig Sæther Bakken wrote:
But just to get back to release frequency, I do think we release too
seldom. There's a lot of process in place now, with a QA branch and
all. I think this process is good, but it's congesting. At this
point we're almost ready to start the
Andi Gutmans wrote:
Speaking of 4.0.7, I think it's time for RC3 and then a quick release
:) Anyone have anything to commit before that?
yes, a bunch of ext/dbplus stuff
i won't touch the config.m4 and it does not interfere with other extensions
afaik i'm the only one to test it anyway and
[Andi Gutmans [EMAIL PROTECTED]]
At 09:12 PM 9/25/2001 +0200, Stig Sæther Bakken wrote:
But just to get back to release frequency, I do think we release too
seldom. There's a lot of process in place now, with a QA branch and
all. I think this process is good, but it's congesting. At this
At 10:48 AM 9/26/2001 +0200, Stig Sæther Bakken wrote:
[Andi Gutmans [EMAIL PROTECTED]]
At 09:12 PM 9/25/2001 +0200, Stig Sæther Bakken wrote:
But just to get back to release frequency, I do think we release too
seldom. There's a lot of process in place now, with a QA branch and
all.
On Wed, 26 Sep 2001, Andi Gutmans wrote:
I think the key still lies in creating a repository for C extensions where
each extension can have its own release cycle.
That is also true, but we still need a reliable way to check for the
version of specific extensions. Having just bumped into an
At 12:01 PM 9/26/2001 -0400, Joao Prado Maia wrote:
On Wed, 26 Sep 2001, Andi Gutmans wrote:
I think the key still lies in creating a repository for C extensions where
each extension can have its own release cycle.
That is also true, but we still need a reliable way to check for the
On Wed, 26 Sep 2001, Andi Gutmans wrote:
I agree completely. We need a way to check what version each extension is.
We have broken BC quite a bit in 4.0.7 so maybe we should add this to 4.0.7
so that we can get this whole external C extension thing going ASAP?
If I could vote on this I
On Wed, 26 Sep 2001, Andi Gutmans wrote:
I think the key still lies in creating a repository for C extensions where
each extension can have its own release cycle.
+1 one for this... :-)
-\- David Eriksson -/-
An expert in a particular computer language is really an expert
in the
I think the key still lies in creating a repository for C extensions
where
each extension can have its own release cycle.
+1 one for this... :-)
Sounds good. I think this would make it easier for the developers of the
extensions AND the developers of the 'main' code. The drawback is that
At 03:12 25-09-01, Jim Winstead wrote:
and i do question, a little bit, how successful our new release
strategy is when we only seem to be able to muster a new release every
three months. but maybe that's a pace we're happy with. and of course,
that has way more to do with a great many more
On Tue, 25 Sep 2001, Stig Sæther Bakken wrote:
I think we should be flexible to make this practical, the core of the
idea is that you should not get any surprises when upgrading just b,
and no API surprises when upgrading m.
There's a question about whether the API should be defined as the
On Tue, 25 Sep 2001, Jani Taskinen wrote:
Like Zeev said, we release new versions too often anyway.
I think we're doing just fine.
-Andrei
The main reason Santa is so jolly is because he knows where
all the bad girls live. -- George Carlin
--
PHP Development Mailing List
At 21:12 25-09-01, Stig Sæther Bakken wrote:
[Zeev Suraski [EMAIL PROTECTED]]
At 03:12 25-09-01, Jim Winstead wrote:
and i do question, a little bit, how successful our new release
strategy is when we only seem to be able to muster a new release every
three months. but maybe that's a pace
On Mon, 24 Sep 2001, Jani Taskinen wrote:
2. General rules for PHP, Zend and PEAR/C-extensions
v.m.b (e.g. 4.0.8)
v = Functions removed, function behaviour changed, API changes,
major parts rewritten. (BC might be broken)
[Andrei Zmievski [EMAIL PROTECTED]]
On Mon, 24 Sep 2001, Jani Taskinen wrote:
2. General rules for PHP, Zend and PEAR/C-extensions
v.m.b (e.g. 4.0.8)
v = Functions removed, function behaviour changed, API changes,
Stig Sæther Bakken [EMAIL PROTECTED] wrote:
Huh? Does strnatcmp() know the that 2.0RC4 is newer than 2.0b2? :-)
probably not. i've always thought that the change needed to make php's
version numbers make more sense is relatively small -- stop ignoring
the middle digit, and use it to signify
There are some customary rules with version numbers. Ignoring them will
result in lots of confusion, as most popular opensource projects use them
(Linux, Apache, MySQL to name a few). Major version number signifies the
'generation', 2nd digit signifies major changes and/or big new chunks of
On Tue, Sep 25, 2001 at 03:00:05AM +0200, Zeev Suraski wrote:
First, you forget that for the vast majority of end users, treating RC's as
releases is going to be nightmarish. RC's are a reality check before
release, and so far, we haven't had a single RC that was release
worthy. Just
20 matches
Mail list logo
