So do you mean all features or just features with changes to their plugins?
I wanted to change the plug-ins as well to make it easier to look at an @since tag and know when the change occurred, but I guess git annotation will reveal this just the same. -- Jeff J. ----- Original Message ----- > From: "Aleksandar Kurtakov" <akurt...@redhat.com> > To: "Linux Tools developer discussions" <linuxtools-dev@eclipse.org> > Sent: Wednesday, September 10, 2014 3:21:31 PM > Subject: Re: [linuxtools-dev] Feature/Plugin versioning policy > > Having features being bumped to the release version and plugins following API > rules sounds like the correct thing to do as that way it's clear what you > install from update sites. > > Alexander Kurtakov > Red Hat Eclipse team > > > ----- Original Message ----- > > From: "Doug Schaefer" <dschae...@qnx.com> > > To: "Linux Tools developer discussions" <linuxtools-dev@eclipse.org> > > Sent: Wednesday, September 10, 2014 10:18:20 PM > > Subject: Re: [linuxtools-dev] Feature/Plugin versioning policy > > > > Actually CDT only bumps up feature versions to match. Plug-ins follow API > > rules. > > > > On 2014-09-10, 3:12 PM, "Jeff Johnston" <jjohn...@redhat.com> wrote: > > > > >There a few different policies for bumping versions for features/plugins. > > > > > >We don't have a hard-set policy, but some of us are bumping up features to > > >the Linux Tools release number and others are bumping up a plugin/feature > > >by one depending on whether we > > >are doing a major release, minor release, or point release. > > > > > >The CDT bumps up all their plug-ins/features to the current release > > >number, but I personally don't like > > >that policy as it can imply a major change to a plug-in has been made and > > >thus API is not guaranteed when > > >no API changes may have occurred. > > > > > >I would like to suggest that code changes made to a plug-in or feature > > >will cause the > > >version to bump to the next Linux Tools release, regardless of the > > >current value. > > >All plug-ins/features that don't change are left alone. The first person > > >to make a change > > >must change the plug-in version and its associated feature version and > > >this should be reviewed > > >in gerrit. > > > > > >This makes it simple to know what has actually been changed in a release > > >vs what has simply > > >been rebuilt. The @since tags then make more sense as to figuring out > > >when changes were made. > > > > > >If people like this, I'll add it to the wiki. > > > > > >-- Jeff J. > > >_______________________________________________ > > >linuxtools-dev mailing list > > >linuxtools-dev@eclipse.org > > >To change your delivery options, retrieve your password, or unsubscribe > > >from this list, visit > > >https://dev.eclipse.org/mailman/listinfo/linuxtools-dev > > > > _______________________________________________ > > linuxtools-dev mailing list > > linuxtools-dev@eclipse.org > > To change your delivery options, retrieve your password, or unsubscribe > > from > > this list, visit > > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev > > > _______________________________________________ > linuxtools-dev mailing list > linuxtools-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev > _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/linuxtools-dev