# Splitting the Autoware.AI repository and changing the organisation

**URL:** <https://discourse.openrobotics.org/t/splitting-the-autoware-ai-repository-and-changing-the-organisation/8139>\
**Category:** Autoware\
**Created:** [March 5, 2019, 7:59am UTC](https://discourse.openrobotics.org/t/splitting-the-autoware-ai-repository-and-changing-the-organisation/8139 "2019-03-05T07:59:36Z")\
**Posts on this page:** 1\
**Showing post:** 22

<div class="post-metadata">

**Author:** ![dirk-thomas](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/dirk-thomas/32/4328_2.png) [@dirk-thomas](https://discourse.openrobotics.org/u/dirk-thomas)\
**Post date:** [March 8, 2019, 9:04pm UTC](https://discourse.openrobotics.org/t/splitting-the-autoware-ai-repository-and-changing-the-organisation/8139/22 "2019-03-08T21:04:57Z")

</div>

> [@esteve](#):
>
> All the core packages must have the same MAJOR.MINOR version to indicate that they are only compatible within each other, but PATCH releases can evolve independently.

Assuming that with “core packages” you refer to the packages in the three repositories starting with “core\_” I think the concept of versioning according to semver collides with the proposal to use the same MAJOR.MINOR.

If there is a breaking change in e.g. `core_perception` you would level its major version following semver. Why should that also result in requiring to level all the other core packages? Users of these APIs shouldn’t be broken. So imo requiring MAJOR.MINOR to be the same eliminates the advantage of versioning the repositories individually.

---

_[View the full topic](https://discourse.openrobotics.org/t/splitting-the-autoware-ai-repository-and-changing-the-organisation/8139)._