Difference between revisions of "LTS/LTS Ready"
< LTS
(New page: The following are the minimum required in order to be considered Long Term Support (LTS) ready: * A distributed version control system capable of pushing branches from repository to repos...) |
(→Release Management) |
||
| (13 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | The following are the minimum required in order to be considered Long Term Support (LTS) ready: | + | The following are the minimum required in order for a project to be considered Long Term Support (LTS) ready: |
| + | ==Code Repository== | ||
* 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 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) | ||
| − | + | ||
| − | + | ==Build== | |
| − | + | A build that builds on Eclipse Foundation hardware and | |
| − | + | ||
| − | + | # Can be cloned/checked out with one step | |
| − | + | # Is documented | |
| − | + | # Is version controlled | |
| − | ## Can refer to compilers and other tools from a configurable location | + | # Is automated |
| − | ## Capable of building without needing an active Internet connection | + | # Is deterministic given the same source code and third party libraries |
| − | ## Capable of pulling dependencies from a known controlled source (e.g. Orbit, Maven, eclipse.org, etc.) | + | # 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 | ||
| + | ## does not depend on proprietary systems other than OS | ||
| + | # Can refer to compilers and other tools from a configurable location '''suggestion:''' | ||
| + | ## must be able to supply JRE locations for 1.4-1.7 We also compile against the following libraries Foundation 1.0, Foundation 1.1, OSGi Minimum 1.1, OSGi Minimum 1.2 See the execution environment on a per bundle basis in the [http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_2.xml#appendix 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) | ||
| + | |||
| + | ==Testing== | ||
| + | |||
| + | A test suite that | ||
| + | # Is version controlled | ||
| + | # Is automated Andrew => is this so in all cases? can and should manual test cases be provided too? | ||
| + | # Documented | ||
| + | |||
| + | ==Bug Tracking== | ||
* Bugs managed in Bugzilla, and possible to have appropriate meta data to manage and track bugs routed to each LTS release version | * Bugs managed in Bugzilla, and possible to have appropriate meta data to manage and track bugs routed to each LTS release version | ||
| + | * It is clearly stated which bugs are in which release. Additionally, no code change can be released without proper bugzilla entry. | ||
| + | |||
| + | ==Release Management== | ||
* Was released as part of the annual simultaneous release | * Was released as part of the annual simultaneous release | ||
| + | OR | ||
| + | * Was approved by a vote of the LTS Steering Committee | ||
| + | |||
| + | ==Supply & Demand (for consideration)== | ||
| + | |||
| + | * At least two LTS IWG member companies offering support | ||
| + | AND | ||
| + | * At least two LTS IWG member companies seeking support | ||
Latest revision as of 18:39, 11 October 2012
The following are the minimum required in order for a project to be considered Long Term Support (LTS) ready:
Contents
Code Repository
- 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)
Build
A build that builds on Eclipse Foundation hardware and
- 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
- does not depend on proprietary systems other than OS
- Can refer to compilers and other tools from a configurable location suggestion:
- must be able to supply JRE locations for 1.4-1.7 We also compile against the following libraries Foundation 1.0, Foundation 1.1, OSGi Minimum 1.1, OSGi Minimum 1.2 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)
Testing
A test suite that
- Is version controlled
- Is automated Andrew => is this so in all cases? can and should manual test cases be provided too?
- Documented
Bug Tracking
- Bugs managed in Bugzilla, and possible to have appropriate meta data to manage and track bugs routed to each LTS release version
- It is clearly stated which bugs are in which release. Additionally, no code change can be released without proper bugzilla entry.
Release Management
- Was released as part of the annual simultaneous release
OR
- Was approved by a vote of the LTS Steering Committee
Supply & Demand (for consideration)
- At least two LTS IWG member companies offering support
AND
- At least two LTS IWG member companies seeking support