Hi,
On 28/03/17 09:09, Michael Dürig wrote:
As Marcel mentions on the issue a better approach would be to release
this independently. If this is blocked by dependencies we should make an
effort to sort this out, as now is the time in the release cycle for
doing so.
So for now -1 from my side to back porting this until
a) we have a clear picture of the alternatives
A group of Oak committers discussed alternatives offline last week. I'd
like to summarize this discussion here on the dev list again. Feel free
to correct me or add to below if you think I missed important conclusions.
In general we recognized the need for this module to work with 1.6.
After all the whole modularization effort is about enabling independent
releases and make it possible to release new features outside of our so
far yearly minor version Oak release cycle. Having to wait for nearly a
year in order to use a rather independent new module with a stable Oak
release seems disproportionate.
An alternative was presented in OAK-4933. Release the new module
independently and then use it in 1.6. The broad agreement in the
discussion last week was, this is not desirable either. We'd end up in a
situation where the 1.6 branch is a mix of multi-module and independent
release modules. The modularization in progress for trunk, with the goal
to have cleaner dependencies also for the new azure module, will make it
more difficult to use the new module in
the 1.6 branch. We definitively don't want to restructure the 1.6 branch
as well.
The proposal therefore is to backport OAK-4933 despite the concerns
mentioned earlier.
b) in the case of backporting, understand how we would ensure quality.
This is new code that was so far never exposed to the level of testing
people would expect from 1.6 code.
I don't have a good answer to this other than thorough code review and
good test coverage. Anything else we can do?
Regards
Marcel
