Hi Joep, On Tue, Mar 6, 2018 at 6:50 PM, J. Rottinghuis <jrottingh...@gmail.com> wrote:
Obviously when people do want to use Ozone, then having it in the same repo > is easier. The flipside is that, separate top-level project in the same > repo or not, it adds to the Hadoop releases. > Apache projects are about the group of people who are working together. There is a large overlap between the team working on HDFS and Ozone, which is a lot of the motivation to keep project overhead to a minimum and not start a new project. Using the same releases or separate releases is a distinct choice. Many Apache projects, such as Common and Maven, have multiple artifacts that release independently. In Hive, we have two sub-projects that release indepdendently: Hive Storage API, and Hive. One thing we did during that split to minimize the challenges to the developers was that Storage API and Hive have the same master branch. However, since they have different releases, they have their own release branches and release numbers. If there is a change in Ozone and a new release needed, it would have to > wait for a Hadoop release. Ditto if there is a Hadoop release and there is > an issue with Ozone. The case that one could turn off Ozone through a Maven > profile works only to some extend. > If we have done a 3.x release with Ozone in it, would it make sense to do > a 3.y release with y>x without Ozone in it? That would be weird. > Actually, if Ozone is marked as unstable/evolving (we should actually have an even stronger warning for a feature preview), we could remove it in a 3.x. If a user picks up a feature before it is stable, we try to provide a stable platform, but mistakes happen. Introducing an incompatible change to the Ozone API between 3.1 and 3.2 wouldn't be good, but it wouldn't be the end of the world. .. Owen
