Hi > Am 08.12.2015 um 12:38 schrieb Michael Dürig <[email protected]>: > > >> >> 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?
Well, in this case, I really suggest to omit version numbers completely since you cannot resonate about versions. As a customer I would not be happy, but that would be the best you as a provider can do. API comes in two flavours: Proper end-developer APIs like the JCR API and the Jackrabbit API. I think this is under control, not the least by having them in separate projects. The other flavour of API is what you might call SPI. This is API that extension developers would leverage to build such things as data stores or indexers. This is AFAICT the problematic one. Maybe you can solve this problem incrementally by starting to create separate, and clean SPI packages which you properly version and then start to deprecate the old API. Regards Felix > > Michael > >> >> Everything else would be a fake compromise which would be totally >> confusing and misleading. >> >> Again, I'm not arguing for one or the other - just stating the options. >> >> Carsten >>
