Hi. Also agree with David, with a small comment that ordering e. g. 4 < 5 is a good convention which adds value around knowing that, for example, the latest version has all the features and bugfixes, whereas a 4.x.y version usually only has some backported changes, if any.
I'm ok with the proposal, but my order of preference is (starting with the highest) : 1. Allow a 0.x.y version space for a while (I didn't have time to look in-depth if the api is sufficient or too much for my/ some needs) 2. Release 1.0.0 3. Release 2.0.0 I maintain my view that matching the version for what it was in sling is not only not helping, but making it a bit confusing when updating dependencies. But it's Ok, I guess. - Andrei On Sat, Feb 9, 2019, 17:01 Raymond Auge <[email protected]> wrote: > If you leverage a baseline tool to help with semantic versioning, it will > not say you anything when it detects a _compatible change_, in theory it's > 100% compatible. > > This means no work for you other than commit and release a bug fix version > of the artifact, no package version changes needed. > > HTH > - Ray > > On Sat, Feb 9, 2019 at 9:45 AM Georg Henzler <[email protected]> wrote: > > > > For now I propose to use the same version as the bundle version but > > > then we > > > must manage it by semantic versioning rules. > > > > +1 > > > > > Especially the package version should never have a bugfix version. So > > > it > > > would be 1.0 or 2.0. > > > > This is interesting, I was not aware that the bugfix version should not > > be used here (just grepping over the Felix Code shows that most places > > use two digits, some use three digits). What's the reasoning behind it? > > (I'm happy to adjust, just want to understand it) > > > > -Georg > > > > > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > (@OSGiAlliance) >
