Closed robstoll closed 4 years ago
the time it takes to build Atrium on travis bothers me already for a longer time. It should be faster. Thus I decided that I will also remove deprecated API modules with 0.10.0. People sticking to en_UK or cc-... can use 0.9.0. Over a longer term they have to migrate to fluent or infix anyway. In the worst case we can ship a 0.9.1 if there are major bugs. So far there have been none in Atrium (none were reported at least) and thus I think this decision should be fine. I'll update the README accordingly and modify the @Deprecated
annotations.
Also not removing deprecated API would make it harder to remove deprecated domain/core modules
I am also in favour of removing deprecated things in 0.10.0. As I wrote in #51, I think it is okay for breaking changes to occur relatively often while the package is still in beta phase.
changed with ef95313c
We stick to the plan, but after discussion in #61 we don't name the version 0.10.0 but 1.0.0 which I like a lot as we break things with a major version and not a minor :)
Atrium has already quite a lot of deprecated functionality. So far I have written in the deprecated annotations, that this functionality stays in Atrium till 1.0.0. However, I have also mentioned in each release that only API is stable, everything else might change without warning. @igorakkerman asked me via slack if we could remove deprecated functionality and proposed that we remove it with 0.10.0. IMO 0.10.0 would be a good moment as we are going to remove the ServiceLoader mechanism, remove the ability to exchange implementations on a jar level (fuse domain-api, domain-robstoll and domain-robstoll-lib into one module, same on core level, remove domain-builders and other things). All this to reduce complexity as we came to the conclusion that this flexibility is not required (more info in #25)
@jGleitz, @name213 objections?