You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2004/05/10 12:03:32 UTC

avalon product release - james/phoenix question

Noel J. Bergman wrote:

>>>Do the non-Merlin-specific packages work with the released version of
>>>Phoenix?  For example, can they be dropped into the James MAIN branch,
>>>and that continue to work properly?
> 
> 
>>The non-Merlin specific packages have been build and tested against all
>>of the cornerstone candidates and validated against JAMES MAIN.
> 
> 
> To be clear: using Phoenix?

The current CVS head of Phoenix builds against the release candidates as 
demonstrated by recent Gump reports.

>>A single conflict exist relative to the James reference to content
>>that was deprecated in excalibur-thread which is handled in james
>>with a special "deprecation handler".  Removal of the handler
>>results in a clean james build and deployment under the Merlin platform.
> 
> 
> Details?

Perhaps the best example would be demonstrated by putting together a 
gump descriptor for James that is container independent.  This would 
provide the James community complete and ongoing going information about 
compatibility of James CVS with Avalon.  In fact, given that the James 
CVS HEAD has no direct Phoenix compile or runtime dependencies - it's 
probably a good idea to just update the existing gump descriptor by 
simply removing the phoenix references.

If your interested in setting up some integration tests then I and 
others can probably put a solution together reasonably quickly based on 
the current Avalon platform.

> 
>>This message is sent to you via James backed by the entire candidate
>>suite (framework, excalibur, util, logging, repository, meta, merlin).
> 
> 
> In the context of my inquiry, I couldn't care less whether Merlin even
> compiles.  We, James, are likely going to want to put out the next release
> after 2.2 using the merged code, and I want to make sure that the released
> version of Phoenix, which is what James uses, works with these new packages.

Phoenix compatibility is not a release criteria.  However, this should 
not be a problem.  Products that choose to remain dependent on the last 
Phoenix release can continue to use the associated packages that are 
known to be compatible.  Alternatively, products can migrate to Merlin - 
Avalon's container solution.

Stephen.

-- 

|---------------------------------------|
| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |
|---------------------------------------|


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: avalon product release - james/phoenix question

Posted by Stephen McConnell <mc...@apache.org>.
peter royal wrote:
> On May 10, 2004, at 6:03 AM, Stephen McConnell wrote:
> 
>>> In the context of my inquiry, I couldn't care less whether Merlin even
>>> compiles.  We, James, are likely going to want to put out the next 
>>> release after 2.2 using the merged code, and I want to make
>>> sure that the released version of Phoenix, which is what 
>>> James uses, works with these new packages
>>
>> Phoenix compatibility is not a release criteria.
> 
> Do we have "release criteria" documented somewhere?

Yes we do.

Within the Avalon documentation you will find the following page 
http://avalon.apache.org/community/process/release.html which basically 
provides a bunch of links.  The closest thing to "release criteria" is 
reflected in the opinion and decisions of the release manager.  The is 
clearly documented under the HTTP release procedure documentation:

   http://httpd.apache.org/dev/release.html

   Regarding what makes it into a release, the RM is the
   unquestioned authority. No one can contest what makes it
   into the release. The community will judge the release's
   quality after it has been issued, but the community can
   not force the RM to include a feature that they feel
   uncomfortable adding. Remember that this document is only
   a guideline to the community and future RMs - each RM may
   run a release in a different way. If you don't like what
   an RM is doing, start preparing for your own competing
   release.

Clearly, release criteria is what the release manager considers 
appropriate and necessary.  In this particular scenario I'm the release 
manager and I consider that a success gump run against a _dead_ product 
as more than sufficient.  Don't forget everyone can download and test 
the candidates against whatever they want - and from that - vote 
accordingly.

Stephen.

-- 

|---------------------------------------|
| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |
|---------------------------------------|


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: avalon product release - james/phoenix question

Posted by peter royal <pr...@apache.org>.
On May 10, 2004, at 6:03 AM, Stephen McConnell wrote:
>> In the context of my inquiry, I couldn't care less whether Merlin even
>> compiles.  We, James, are likely going to want to put out the next 
>> release
>> after 2.2 using the merged code, and I want to make sure that the 
>> released
>> version of Phoenix, which is what James uses, works with these new 
>> packages.
>
> Phoenix compatibility is not a release criteria.

Do we have "release criteria" documented somewhere?

Otherwise, how was Phoenix removed from this list?

Unless there are insurmountable or very difficult technical reasons not 
to do so, our releases should be backwards-compatible with our previous 
releases. Especially with one of the most widely-used Avalon containers 
out there.
-pete


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org