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
