You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2010/11/11 16:12:38 UTC

Versioning the Eclipse Update Site

While preparing the 2.3.1 UIMA SDK release, I updated in my working copy the
Eclipse Update site.  I even tested it - it worked OK with 3.6.1 Eclipse.

Previously, we sometimes managed to release everything more or less together. 
At our last release (2.3.0) we made the Eclipse update site have a version which
was 2.3.0.

I think this model is broken, though.

Going forward, it still makes sense to have the eclipse "feature" projects at
particular versions which correspond to uima component releases.  So, for
instance, we have the uima tools feature at 2.3.1, and the uima runtime feature
at 2.3.1.  These feature projects bundle together (sometimes) as set of plugins
at a particular release level.

Later, when we release uima-as descriptor editor, that could be at 2.3.1, also. 
When that happens, the main update-site project (which builds the update site)
will need a new version number.  So if it was 2.3.1, it would need to be 2.3.2
or ??.  This seems wrong.

I think we should assign version numbers to the update site (which will have a
new release anytime any of the features its holding get released) that are more
like build tools.  I would start at "3", and just increment this by 1 for each
release.

The version of the update site doesn't show in Eclipse - what shows there is the
versions of the features at the update site.

What do others think?

-Marshall

Re: Versioning the Eclipse Update Site

Posted by Tommaso Teofili <to...@gmail.com>.
Hi Marshall,


2010/11/11 Marshall Schor <ms...@schor.com>

> While preparing the 2.3.1 UIMA SDK release, I updated in my working copy
> the
> Eclipse Update site.  I even tested it - it worked OK with 3.6.1 Eclipse.
>
> Previously, we sometimes managed to release everything more or less
> together.
> At our last release (2.3.0) we made the Eclipse update site have a version
> which
> was 2.3.0.
>
> I think this model is broken, though.
>
> Going forward, it still makes sense to have the eclipse "feature" projects
> at
> particular versions which correspond to uima component releases.  So, for
> instance, we have the uima tools feature at 2.3.1, and the uima runtime
> feature
> at 2.3.1.  These feature projects bundle together (sometimes) as set of
> plugins
> at a particular release level.
>
> Later, when we release uima-as descriptor editor, that could be at 2.3.1,
> also.
> When that happens, the main update-site project (which builds the update
> site)
> will need a new version number.  So if it was 2.3.1, it would need to be
> 2.3.2
> or ??.  This seems wrong.
>
> I think we should assign version numbers to the update site (which will
> have a
> new release anytime any of the features its holding get released) that are
> more
> like build tools.  I would start at "3", and just increment this by 1 for
> each
> release.
>

+1 very good point, I think your suggestion is good.
Tommaso


>
> The version of the update site doesn't show in Eclipse - what shows there
> is the
> versions of the features at the update site.
>
> What do others think?
>
> -Marshall
>