----- Original Message ----- > From: "Aleksandar Kurtakov" <akurt...@redhat.com> > To: "Linux Tools developer discussions" <linuxtools-dev@eclipse.org> > Sent: Wednesday, September 10, 2014 5:36:29 PM > Subject: Re: [linuxtools-dev] Feature/Plugin versioning policy > > ----- Original Message ----- > > From: "Jeff Johnston" <jjohn...@redhat.com> > > To: "Linux Tools developer discussions" <linuxtools-dev@eclipse.org> > > Sent: Wednesday, September 10, 2014 10:28:42 PM > > Subject: Re: [linuxtools-dev] Feature/Plugin versioning policy > > > > So do you mean all features or just features with changes to their plugins? > > All features. So when one looks in the p2 ui it is clear that every feature > comes from certain release. >
Ok, so matching CDT (now that I know what they are doing). I have been bumping up a few features to 3.1.0 that specifically have N&N items (e.g. devhelp feature). I could do all the features for RC4 or leave it for 3.2.0. I'm fine either way. > > > > 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. > > That would be a bit too much I think though I would not mind it that way if > decided (I use this practice for shelled/fedorapackager as it's plain > easier). > Ok, agreed. > Alexander Kurtakov > Red Hat Eclipse team > > > > > -- 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 > > > _______________________________________________ > 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
