The following are the minimum required in order for a project to be considered Long Term Support (LTS) ready:
- A distributed version control system capable of pushing branches from repository to repository. This repository should be one that is supported at the Eclipse Foundation. (e.g. Git)
A build that
- Can be cloned/checked out with one step
- Is documented
- Is version controlled
- Is automated
- Is deterministic given the same source code and third party libraries
- Is easily reproducible on suitably-configured systems TODO: Can we define this a little better? suggestion:
- has git >=1.7
- has java >=6.0
- has maven 3.0.3
- does it even need an eclipse SDK install? If so, I'd suggest Indigo as a baseline
- Can refer to compilers and other tools from a configurable location suggestion:
- must be able to supply JRE locations for 1.4-1.7 Kim: We compile against the following libaries Foundation 1.0, Foundation 1.1, See the execution environment on a per bundle basis in the project plan.
- to support the next requirement, must be able to supply local mirrors of required p2 repositories (orbit, indigo/juno, etc)
- signing at eclipse.org needs to be optional but configurable?
- Capable of building without needing an active Internet connection question:
- does maven/tycho cache the bundles it needs from p2 repos in the local maven repo, so having run once you don't need your connection anymore?
- Capable of pulling dependencies from a known controlled source (e.g. Orbit, Maven, eclipse.org, etc.)
- Adheres to Eclipse IP policies (esp. with regards to third party code)
- Bugs managed in Bugzilla, and possible to have appropriate meta data to manage and track bugs routed to each LTS release version
- Was released as part of the annual simultaneous release