Leo Simons wrote:

Stephen McConnell wrote:

Berin Loritsch wrote:

Stephen McConnell wrote:


Berin:


This should be under the avalon CVS, not excalibur. It not a utility - it's a couple of interfaces that define extensions to the framework contract.


:/ I don't think you are going to get consensus on that.


Lets' discuss it and see.


consider it shown!


Leo ...:-)

What is shown? It's being dicussed. I don't see a conclusion just yet.

I think Berin is making the right move :D


I think Berin is making the right move in terms of moving forward on the release. I don't think the Excalibur CVS is a good move - for a number of reasons (see prior email).


Esp. since
by the time we are done with handling these things, they might go
away.


Sorry - I'm using extensions and I'm not about to drop support for extensions.


yeah but that doesn't mean avalon as a whole is required to support extensions.


I didn't say avalon as a whole is required to support extensions.
I don't think that avalon as a whole is required to support extensions.

Remember that this is alpha code which has not been subject to a release vote, so you should not assume consensus (just the lazy variant). Given the massive amount of discussions surrounding this stuff, I think it is safe to assume there isn't consensus.


I think the term "this is alpha code" is missleading and creates the suggestion of a risk that frankly is not there. Please - I would suggest that people take a look at the lifecycle package - any you find a couple of interfaces that define a contract together with a bunch of good documentation. You will find information about containers that provide support. We are not dicussing the containers or their respective status - we are discussing the release of the lifecycle extension package which is basically the interfaces that detail a contractual extension between a container and a component.


If extensions are voted down, avalon is going to drop support for them. That would mean you would have to do your support for them elsewhere.


Take a look at the package - what support?
Two interfaces - there isn't any support here - the works been done.



I understand your position, but in order to get a release RSN I
suggest going with the least radical path towards adoption.


I'm tempted to say that this strategy will backfire.


why?


Because the Berin's suggestion to move the lifecycle package into excalibur is based on eliminated the need to address the real question. The real question is about the release of a package that defines a contract for component lifecycle extension. It need not be the only one - but but releasing this we are saying that Avalon - this community - is endorcing an approach to lifecycle extension at the framework level. This does not make it a mandatory extension to the framework and does not force anything. But it is important and should be treated as such.

Even we are releasing the lifecycle package or not. If we release it we should do it properly.


why is releasing it as an independent package "improper"?


Because releasing this under excalibur is inconsistent. It is not a utility or a component. It is contractual extension relative to the framework. This is distinclty different from everything else in excalibur.


Currently the avalon CVS contains the framework. This does not mean that framework is the only project at this level. We have already discussed the need to start work on the seperation of framework imp and interfaces which means we will rapidly being seeing the emergence of at least two projects in framework. The lifecycle extension simply belong at this level. I am not suggesting that the extension interfaces be included in framework - only that that the extension package belongs in the avalon cvs - not excalibur.


I suggest we deal with cvs (re)structuring after "Excalibur phase III" and phoenix 4.1 have been released, at least. Right now more moving of packages will just cause further delays. We need to get to "release early release often".


This is trivial. The package over on sandbox is well setup and can be moved to the "appropriate" place with minimum effort.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to