Michael Dürig wrote > >> >> The development model of Oak is currently setup in a way which makes it >> impossible to do semantic versioning of the API. The main reason is that >> the branches are not just maintenance branches but also features are >> backported to the branches. And the way this is done also means that the >> API on such a branch could be "different" to the main branch and evolve >> differently. Which in consequence means it's not compatible anymore >> (things added to the branch might evolve differently on the main branch >> - this might be more theory than practice, but it can happen). > > Currently this happens all the time and I fear there is little we can do > about it for the time being. > >> Therefore, with the current way of doing development in Oak, semantic >> versioning is not possible. Period. > > Right, this is also my impression. > >> >> You have two options: provide meaning to the API versions (which means >> changing the way development is done in general), or stick to the >> current way and clearly state that there is no semantic versioning. > > My question would be, how can we get there incrementally? There is no > way for us to do a big bang refactoring as there are too much > dependencies already. > One idea that crossed my mind was to remove semantic versioning for the > stuff we only export for consumption by ourselves and which we optimally > would want to hide from the rest of the world anyway. These are the > parts that see most changes. The "real public APIs" are much more stable > and we should be able do proper semantic versioning for those. Could > such an approach work? > I think so. This distinction makes sense to me and it would give at least the typical users a stable, semantically versioned API.
Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
