separate versioning of modules vs. @Alpha @Beta annotations

[GoogleCodeExporter]

Right now, we maintain separate versions of each ClearTK module, instead of the 
standard Maven approach, which gives all modules within a multi-module project 
the same version. The major downside of this approach is that it makes releases 
much slower and more complicated. Each module has to be released separately, 
and the releaser has to make sure to release modules in the proper order based 
on the tree of dependencies. The major upside of the separate versions is that 
we can mark some code as being less mature than other code.

An alternative would be to follow the Guava approach: release all ClearTK 
modules with the same version, but introduce @Beta (and maybe @Alpha) 
annotations to mark APIs which are still experimental.

Original issue reported on code.google.com by steven.b...@gmail.com on 29 May 2013 at 9:46

[GoogleCodeExporter]

We agreed to set all modules to the same version (e.g. 2.0.0 for the next 
release).

If modules start to decay (e.g. like cleartk-semantic-roles did), we'll break 
them off into a separate project (not in the list of modules), and make them 
depend on a fixed version of ClearTK. (Until we eventually decide to delete 
them entirely.)

Original comment by steven.b...@gmail.com on 25 Jun 2013 at 4:51

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was closed by revision a4bd111c0792.

Original comment by steven.b...@gmail.com on 25 Jun 2013 at 9:35

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****