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

[Jeff Johnston <jjohnstn@xxxxxxxxxx>]

----- Original Message -----
> From: "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx>
> To: "Linux Tools developer discussions" <linuxtools-dev@xxxxxxxxxxx>
> Sent: Wednesday, September 10, 2014 5:36:29 PM
> Subject: Re: [linuxtools-dev] Feature/Plugin versioning policy
> 
> ----- Original Message -----
> > From: "Jeff Johnston" <jjohnstn@xxxxxxxxxx>
> > To: "Linux Tools developer discussions" <linuxtools-dev@xxxxxxxxxxx>
> > 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" <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
> > > 
> > _______________________________________________
> > 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
>