Re: [linuxtools-dev] Feature/Plugin versioning policy

[Jeff Johnston <jjohnstn@xxxxxxxxxx>]

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" <akurtako@xxxxxxxxxx>
> To: "Linux Tools developer discussions" <linuxtools-dev@xxxxxxxxxxx>
> 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" <dschaefer@xxxxxxx>
> > To: "Linux Tools developer discussions" <linuxtools-dev@xxxxxxxxxxx>
> > 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" <jjohnstn@xxxxxxxxxx> 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@xxxxxxxxxxx
> > >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@xxxxxxxxxxx
> > 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@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
>