blob: 9bb607adabde3683973ceed74523705966a6e8e2 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<?xml-stylesheet type="text/xsl" href="http://www.eclipse.org/projects/project-plan.xsl"?>
<plan plan-format="1.0" xmlns="http://www.eclipse.org/project/plan" xmlns:html="http://www.w3.org/1999/xhtml"
name="Project Name">
<release projectid="technology.dash" version="1.0"/>
<introduction>
<html:div>
The EGit project provides two major technologies:
<html:ul>
<html:li>
JGit, a pure Java implementation of the Git version control system.
The JGit component is licensed under the <html:a href="http://www.eclipse.org/org/documents/edl-v10.php">EDL</html:a>
and has only BSD licensed dependencies.
</html:li>
<html:li>
EGit, an Eclipse team provider plugin which relies upon JGit to
access local and remote Git repositories.
</html:li>
</html:ul>
</html:div>
</introduction>
<release_deliverables>
<html:div>
Working EGit team provider plugin delivered via EGit p2 repository.
JGit plain Java libraries delivered via JGit Maven repository, JGit command line application can be downloaded
from JGit Maven repository or from download page as separate archive and JGit OSGi bundles are delivered via the
EGit p2 repository.
</html:div>
</release_deliverables>
<release_milestones>
<preamble>
<html:div>JGit and EGit aim at publishing releases every 3 months and try to synchronize
this schedule with the release train schedule (with new release train releases every June,
and with service releases SR1 each September and SR2 each February).</html:div>
</preamble>
<milestone date="12/21/2011" milestone="1.2.0"><html:div></html:div></milestone>
<milestone date="2/15/2012" milestone="1.3.0"><html:div>1.3 available with Indigo SR2,
clean and evolve API, gc support, recursive merge support, stash support, submodule support</html:div></milestone>
<milestone date="6/2012" milestone="2.0"><html:div>2.0 available with Juno, stash support, apply patch,
support for Eclipse-SourceReferences manifest headers, workspace patches, push of single refs/commits,
performance improvements</html:div></milestone>
<milestone date="9/2012" milestone="2.1"><html:div>2.1 available with Juno SR1, jgit gc support,
include in all relevant EPP packages, ship with SDK by default</html:div></milestone>
<postamble><html:div></html:div></postamble>
</release_milestones>
<target_environments>
<html:div>
For the EGit team provider, any Java 5 or later platform that runs
the Eclipse workbench.
</html:div>
<html:div>
For the EGit 0.9 until 0.12 team provider, Eclipse workbench 3.5.2 or later.
</html:div>
<html:div>
For EGit 0.11 and later, also Eclipse workbench 4.1 (or later) with 3.7 (or later)
compatibility layer.
</html:div>
<html:div>
For EGit 1.3 and later, minimum Eclipse workbench version is 3.6.2.
</html:div>
<html:div>
For EGit 2.0 and later, minimum Eclipse workbench version will be 3.7.2,
also Eclipse workbench 4.2 (or later) with 3.8 (or later)
compatibility layer will be supported.
</html:div>
<html:div>
For the JGit library, any Java 5 or later standard edition platform,
without git-core or any other Eclipse product installed.
</html:div>
<internationalization>
<html:div>
Only English translation files, however all strings
are externalized for translation in a future release.
</html:div>
</internationalization>
</target_environments>
<compatibility_with_previous_releases>
<html:div><html:strong>API Compatibility:</html:strong>EGit as of now has no public API. JGit 1.3 will be compatible with APIs declared in earlier 1.x releases,
JGit 2.1 will be compatible with APIs declared in 2.0.</html:div>
<html:div><html:strong>Workspace compatibility:</html:strong>Workspaces being used with EGit 1.0 and later should still open and work with later EGit releases.</html:div>
<html:div><html:strong>Project compatibility:</html:strong>Projects being used with EGit 1.0 and later should still open and work with later EGit releases.</html:div>
<html:div><html:strong>Non-compliant usage of API's:</html:strong> All non-API methods and classes, and certainly everything in a package with "internal" in its name
or x-internal in the bundle manifest entry, are considered implementation details which may vary between operating environment and are subject
to change without notice. Client plug-ins that directly depend on anything other than what is specified in the JGit API are inherently
unsupportable and receive no guarantees about compatibility within a single release much less with earlier releases.</html:div>
</compatibility_with_previous_releases>
<themes_and_priorities>
<preamble>
<!-- <html:div>Some xhtml content here. Make sure to use the prefix before the elements</html:div> -->
</preamble>
<theme name="Usability">
<!-- <description>...(optional) html...</description>
<committed bugzilla="...(recommended) bugzilla search url...">
...(optional alternate) html...</committed>
<proposed bugzilla="...(recommended) bugzilla search url...">
...(optional alternate) html...</proposed>
<deferred bugzilla="...(recommended) bugzilla search url...">
...(optional alternate) html...</deferred> -->
</theme>
<theme name="Enable use without command-line git">
</theme>
<theme name="Documentation Improvements">
</theme>
<theme name="Building a Community">
</theme>
</themes_and_priorities>
<!-- <appendix name="Project Refactoring">
...html...
</appendix> -->
</plan>