Jyri Virkki wrote:
> Sriram Natarajan wrote:
>
>> Let us say - for nevada build 74, we are shipping Apache 2.2.4 and the
>> appropriate PHP 5.2.3 module for apache. Now, let us assume for Nevada
>> build 90, PHP comes up with a PHP 5.4.2 release . So, at the time of
>> Nevada build 90 release, we will be bundling Apache 2.2.40 and the also
>> the appropriate PHP 5.2.18 and PHP 5.4.2 modules for Apache 2.2 Hmm..
>> starts getting interested.
>>
> [...]
>
> Builds are not releases, that's what overcomplicates your example.
>
My assumption was that the build number that I had given above as
example will turn out to be actual releases (You know - like a quarterly
developer release that Nevada releases)
> Right now in ~b74 timeframe it is 2.2.4 and 5.2.3. If newer versions
> come out in the coming months we'll probably switch to them assuming
> they work ok and cause no undue disruptions. The old version is gone.
>
If they are going to be gone, then does this mean, we will only release
a single version of each component release within SAMP stack. If so,
why bother add version information (either /usr/apache2/2.2 or
/usr/apache2.2) ?
> At some point the build trains come to an end and there is an actual
> release (S11, Indiana, whatever). When that release comes out it will
> only have one Apache 2.x and one PHP version.
>
>
Hmm.. doesn't that void the multiple release flexibility that some folks
are asking for .
