uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject managing multiple version streams
Date Fri, 12 Jan 2018 16:50:02 GMT
Thoughts, discussion needed:

When we started this project, we imagined we were creating some artifacts, each
of which would have multiple versions marching forward in time, but each version
superseding the previous.

We set up svn to have a top level name for each sub-big-project (e.g. uimaj,
uima-cpp, ducc, uimaFIT, Ruta, etc.), and under that
  -trunk
  -tags
  -branches

following normal conventions.  Our build tools are based around this convention.
--------------------------
Now, we are beginning to see the need for multiple versions where some of these
will continue to be maintained. 

  - For example, uimaj now has version 2.10.2 and (soon) version 3.0.0. 

  - And uima-as may soon have also a version 2.x and (soon) a restructured
(maybe slightly incompatible) version 3.x (not related to uimaj 3.x).

  - other projects may also have multiple maintained versions that work with
uimaj-v3 and uima-v2
--------------------------
One choice might be to have new names for maintained versions, that reflect
something identifyable about them.  For instance, we might have:

  - uimaj-v3 (old name, version starts at 3.0.0 ) ->  uimaj-j (version starts at
1.0.0, or 3.0.0)
  - <the new as yet unnamed refactored version of uima-as> -> uima-as-r (version
starts at 1.0.0 or ??)

(Please excuse the poor names, they're just for an example)
--------------------------
If we went this route, these new big-projects would live in the svn hierarchy
along side the other projects.  So for example we might have

uima (top level svn)
  uimaj
  uimaFIT
  ducc
  ruta
  uima-as
  uimaj-j
  uima-as-r

and under each of these, there would be a "release" process, making shared use
of our uima-wide superpom which in turn makes use of conventions of having under
these directories a "trunk" and a "tag", etc.
---------------------------
If uimaFIT wanted two versions maintained, one being one that worked with uimaj
and the other that worked with uimaj-j, it would perhaps have two top level
projects:
  uimaFIT
  uimaFIT-j  (sorry for the name... just adopting the single letter suffix from
uimaj -> uimaj-j)
and, the same would apply to uima-as and uima-as-r:
  uima-as-j
  uima-as-j-r

Some of these projects could be tiny.  For example the version of uima-as that
works with uimaj-j has only POM changes versus the uima-as project (plus some
small code change I think that could probably be parameterized somehow).

It might be possible to have just one project for uima-as for the uimaj/uima-j
combo, if we could figure out how to build two different (named) artifacts when
doing builds for releasing the binary form.
-------------------------
The current svn organization collects the xxx-j style projects (those that
depend on uimaj-v3) underneath an "extra" top level node in the svn directory:
uv3/.  And it names those projects with the suffix -v3. 
-------------------------
I think the suffix "-v3" is potentially confusing (going forward) because of the
need for other projects to claim a v3 for a completely unrelated purpose. 
Example, the reworking of uima-as, changing things so that semantic versioning
says it needs to increment the 1st digit - will have a version 3.0.0 (completely
unrelated to uimaj-v3). 
So, I think (as a minimum) we should rename the uv3 moniker to something not
version specific, like uimaj-j. 
-------------------------

Please consider these issues, and make improvements / suggestions :-)

-Marshall





Mime
View raw message