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
