Hi Gunnar,
seems I still don't understand proper OSGi versioning correctly. So I'm happy about feedback.
> I'd like to review the API change you had to do for a bug fix.
In ColumnGroupReorderLayer we needed to add the method updateColumnGroupModel() and we needed to introduce two new classes GroupColumnReorderStartCommandHandler and GroupColumnReorderEndCommandHandler.
Do you need some more information?
> From an OSGi point of view, you should do the proper versioning at the package level.
I have to admit that we simply updated all package versions. Should we avoid this and only update the version for the packages were something has changed?
We could modify this for the 1.3.0 release since we only have a few changes.
This question is related to the next question. Maybe then I get a better understanding.
> I don't think it necessarily mandates a minor release at the bundle level.
Aren't the bundle version and the package versions somehow correlated? I mean, if I increase a package version to 1.3.0, doesn't that mean I also have to update the bundle version? Because there is a package with a higher version than the bundle? Or are package versions and bundle versions completely separated from each other. Which then means we could have a package with version 27.3.0 while our bundle version is still something like 1.3.42?
I'm a bit confused about the versioning regarding packages and bundles now.
Nevertheless, since we decided to release a 1.3.0, we also decided to add two small enhancements which introduce new public methods. Therefore we have two small new features and a 1.3.0 seems to be OK then I guess. But it would be interesting to know about correct versioning for the future. We can only get better.
Greez,
Dirk
