Carsten Ziegeler wrote:
It is even smoother than that, albeit one could argue whether it would confuse someone looking under the hood.What about creating a 4.1.x branch, add the bug fixes etc. andBerin Loritsch wrote:
It seems that merely relying on Framework 4.1.x is not really going to be an option because the IMPL has some fixes that we need. Unfortunately, there is the big question of the change in constructor policy. We can't really say we support Avalon Framework contracts for
4.2 at this point--but at the same time there are some fixes to the utilities that we need that are in 4.2.
Unfortunately the damage is done, so we need to address how to avoid this scenario in the future.
My suggestion is this:
* Any bug fixes get released separately from contract changes.
* Any contract changes must have a lot of noise surrounding them so that there can be decent communication between the projects that depend on the framework.
This way, the framework compatibility is preserved in the widest context, and important bug fixes don't get lost because we don't want to upgrade to the latest and greatest new contract *yet*.
do a 4.1.6 release?
You can simply use the avalon-framework-api-4.1.5.jar and avalon-framework-impl-4.2.0.jar, and bicker me if in the future the 'latest' Impl isn't compatible with the 4.1.5 API. Because this is my intention for the Framework 4.x.
Sounds reasonable.
Cheers Niclas
P.S. Alternative, nothing says you can't ship 4.2, if your docs states that you follow the 4.1 contract. That is completely valid arrangement as well.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
