Difference between revisions of "LDT/Developer Area/Development"

From Eclipsepedia

< LDT
Jump to: navigation, search
(Bugzilla severity and priority)
(Maintenance Milestone)
(7 intermediate revisions by 3 users not shown)
Line 33: Line 33:
 
|-
 
|-
 
|normal
 
|normal
|A problem making a function difficult to use but no special work around is required
+
|Not used in Koneki (Default value in Bugzilla, so can mean a bug has not been sorted)
 
|-
 
|-
 
|minor
 
|minor
Line 42: Line 42:
 
|-
 
|-
 
|enhancement
 
|enhancement
|A new feature
+
|A new feature or improvement of an existing one
 
|}
 
|}
  
Line 57: Line 57:
 
|-
 
|-
 
|P3
 
|P3
|Would be fixed before release, but maybe we will not manage.
+
|Would be fixed before release, if possible.
 
|-
 
|-
 
|P4
 
|P4
Line 79: Line 79:
  
 
All the old releases can be found in /home/data/httpd/archive.eclipse.org/koneki/releases. (with the same structure)
 
All the old releases can be found in /home/data/httpd/archive.eclipse.org/koneki/releases. (with the same structure)
 +
 +
= APITools =
 +
All the org.eclipse.koneki.ldt* plugins are checked against APITools to ensure the consistence of LDT public API.
 +
When checkouting the code in an eclipse workspace, you must set an API baseline used by APITool check your development against, in our case, the API baseline have to be the last stable version of the LDT standalone product. To work on the LDT remote feature, you have to install the last stable version of remote feature in the product used as reference.
 +
 +
The API baseline can be set in the eclipse preference under the menu "Plug-in development/Api baseline".
 +
 +
To go further with Api Tool, see the related wiki: http://wiki.eclipse.org/PDE/API_Tools.
  
 
= Delivery Process =
 
= Delivery Process =
 
All the path in this section are relative to <tt>/home/data/httpd/download.eclipse.org/koneki</tt> on <tt>build.eclipse.org</tt>
 
All the path in this section are relative to <tt>/home/data/httpd/download.eclipse.org/koneki</tt> on <tt>build.eclipse.org</tt>
  
=== Maintenance version ===
+
=== Maintenance versions delivery ===
 +
 
 +
==== Maintenance Milestone ====
 
*"Commit freeze" on all maintenance branches.
 
*"Commit freeze" on all maintenance branches.
 
*Be sure the last version build corresponds to the last commit wanted.  
 
*Be sure the last version build corresponds to the last commit wanted.  
 
*Test the last nightly-maintenance build.
 
*Test the last nightly-maintenance build.
If tests are ok:
+
*execute script releases:
*Copy all directories from <tt>updates-nightly-maintenance/</tt> to <tt>releases/stables/${NUM.VERSION}</tt>.  
+
<tt>python erclt.py mm -mv 1.0.1RC1</tt>
** <tt>mkdir releases/stable/${NUM.VERSION}/</tt>
+
which do :
** <tt>cp -r updates-nightly-maintenance/* releases/stable/${NUM.VERSION}/</tt>
+
  Deliver a new milestone repo.
*Rename the repository name in <tt>compositeArtifacts.xml</tt> and <tt>compositeContent.xml</tt> in <tt>releases/stables/${NUM.VERSION}</tt> (increment timestamp too)
+
  Deliver new milestone products.
** <tt>sed -i -e "s/(nightly-maintenance)/(${NUM.VERSION})/g" releases/stable/${NUM.VERSION}/compositeArtifacts.xml</tt>
+
*Tag the last commit of the maintenance branches.
** <tt>sed -i -e "s/(nightly-maintenance)/(${NUM.VERSION})/g" releases/stable/${NUM.VERSION}/compositeContent.xml</tt>
+
 
** (increment timestamp)
+
==== Maintenance Minor versions ====
*Modify repo to enable statistic
+
*Test the milestones version which is the releases candidate.
*Add child <tt>${NUM.VERSION}</tt> in the repository name in <tt>compositeArtifacts.xml</tt> and <tt>compositeContent.xml</tt> in <tt>releases/stables/</tt> (increment timestamp too)
+
If tests are ok :
*Check the files permissions. (all repo should have directory with right  drwxrwsr-x and artifacts.jar and content.jar in -rw-rw-r--)
+
*execute script releases:
*Tag the last commit of the maintance branches.
+
<tt>python erclt.py ms -mv 1.0.1RC1 -sv 1.0.1 </tt>
** name ${NUM.VERSION}, description : Releases ${NUM.VERSION} version
+
 
 +
which do :
 +
  Deliver stable repo.
 +
  Archive milestones repo.
 +
  Deliver stable products.
 +
  Archive milestones products.
 +
 
 +
If script execution is ok:
 +
*Tag the maintenance branches.
 
*Increment version to the next maintenance version then commit it.
 
*Increment version to the next maintenance version then commit it.
** commit comment : Increment version (${OLD.VERSION} => ${NUM.VERSION})
 
*Deliver new products.
 
** archive current version : <tt>cp products/stable/* /home/data/httpd/archive.eclipse.org/koneki/products/stable/${CURRENT.NUM.VERSION}/</tt>
 
** deliver new version : <tt>cp /shared/jobs/koneki-ldt-maintenance/lastSuccessful/archive/product/target/products/* products/stable</tt>
 
  
=== Milestones versions ===
+
=== Stables versions delivery ===
 +
==== Milestones versions ====
 
*"Commit freeze" on all master branches.
 
*"Commit freeze" on all master branches.
 
*Be sure the last version build corresponds to the last commit wanted.  
 
*Be sure the last version build corresponds to the last commit wanted.  
Line 122: Line 137:
 
*Tag the last commit of the master branches.
 
*Tag the last commit of the master branches.
  
=== Major versions ===
+
==== Major versions ====
 
*Test the milestones version which is the releases candidate.
 
*Test the milestones version which is the releases candidate.
 
If tests are ok :
 
If tests are ok :
Line 156: Line 171:
 
* Increment product version and its dependencies version
 
* Increment product version and its dependencies version
 
* Increment feature version includes in category.xml
 
* Increment feature version includes in category.xml
* Increment documentation version (org.eclipse.koneki.ldt.doc.user/build-help.xml and org/eclipse/koneki/ldt/debug/ui/DocumentationLinksConstants.java)
+
* Increment documentation version (org.eclipse.koneki.ldt.doc.user/build-help.xml, org/eclipse/koneki/ldt/debug/ui/DocumentationLinksConstants.java and plugin.xml)
 
* deploy User guide (wiki)
 
* deploy User guide (wiki)
 
* Update Koneki website links to the wiki user guide.
 
* Update Koneki website links to the wiki user guide.
 
  
 
=== Enable Statistic ===
 
=== Enable Statistic ===

Revision as of 08:35, 3 September 2013

Contents

Git repositories

Koneki source code is available on the Git repositories of the Eclipse Foundation. There are several repositories:

org.eclipse.koneki.commons.git Contains plug-ins that aim at being re-used by other Koneki projects (generic UI components, helpers, ...)
org.eclipse.koneki.ldt.git Contains the Lua Development Tools source code
org.eclipse.koneki.protocols.git Contains different sub-projects providing the core components enabling protocols (OMA-DM, ...) manipulation in the tools
org.eclipse.koneki.simulators.git Contains different sub-projects providing the components enabling protocols (OMA-DM, ...) simulation in the tools

Bugzilla severity and priority

Severity Definition
blocker A problem preventing a function from being used, no work around, blocking progress on multiple fronts
critical A problem preventing a function from being used, no work around
major A problem preventing a function from being used, but a work around is possible
normal Not used in Koneki (Default value in Bugzilla, so can mean a bug has not been sorted)
minor A problem not affecting the actual function, but the behavior is not natural
trivial A problem not affecting the actual function, a typo would be an example
enhancement A new feature or improvement of an existing one


Priority Definition
P1 Must be fixed within the current milestone.
P2 Must be fixed before the release.
P3 Would be fixed before release, if possible.
P4 Would be probably fixed someday.
P5 Not important to our long-term plans.

Update sites organization

The active Hudson jobs perform the continuous integration of Koneki projects and deploy signed p2 repos to the nightly update sites.

There are 2 kind of nightly updates sites (repositories) :

  • nightly: /home/data/httpd/download.eclipse.org/koneki/updates-nightly, which is a composite repo of the last successful builds of the 'master' branch of each Koneki projects.
  • nightly-maintenance: /home/data/httpd/download.eclipse.org/koneki/updates-nightly-maintenance, which is the same one but for the active maintenance branch.

All the last releases are stored in /home/data/httpd/download.eclipse.org/koneki/releases repository which is composed of :

  • stable: /home/data/httpd/download.eclipse.org/koneki/releases/stable which contains all the last stable releases.
  • milestones: /home/data/httpd/download.eclipse.org/koneki/releases/milestones which contains all the last milestones.

All the old releases can be found in /home/data/httpd/archive.eclipse.org/koneki/releases. (with the same structure)

APITools

All the org.eclipse.koneki.ldt* plugins are checked against APITools to ensure the consistence of LDT public API. When checkouting the code in an eclipse workspace, you must set an API baseline used by APITool check your development against, in our case, the API baseline have to be the last stable version of the LDT standalone product. To work on the LDT remote feature, you have to install the last stable version of remote feature in the product used as reference.

The API baseline can be set in the eclipse preference under the menu "Plug-in development/Api baseline".

To go further with Api Tool, see the related wiki: http://wiki.eclipse.org/PDE/API_Tools.

Delivery Process

All the path in this section are relative to /home/data/httpd/download.eclipse.org/koneki on build.eclipse.org

Maintenance versions delivery

Maintenance Milestone

  • "Commit freeze" on all maintenance branches.
  • Be sure the last version build corresponds to the last commit wanted.
  • Test the last nightly-maintenance build.
  • execute script releases:

python erclt.py mm -mv 1.0.1RC1 which do :

 Deliver a new milestone repo.
 Deliver new milestone products.
  • Tag the last commit of the maintenance branches.

Maintenance Minor versions

  • Test the milestones version which is the releases candidate.

If tests are ok :

  • execute script releases:

python erclt.py ms -mv 1.0.1RC1 -sv 1.0.1

which do :

 Deliver stable repo.
 Archive milestones repo.
 Deliver stable products.
 Archive milestones products.

If script execution is ok:

  • Tag the maintenance branches.
  • Increment version to the next maintenance version then commit it.

Stables versions delivery

Milestones versions

  • "Commit freeze" on all master branches.
  • Be sure the last version build corresponds to the last commit wanted.
  • Test the last nightly build.

If tests are ok:

  • execute script releases:

python erclt.py m -mv 0.9RC2

which do :

 Deliver repo.
 Deliver new products.
 

If script execution is ok:

  • Tag the last commit of the master branches.

Major versions

  • Test the milestones version which is the releases candidate.

If tests are ok :

  • execute script releases:

python erclt.py s -mv 0.9RC2 -sv 0.9

which do :

 Archive stable repo.
 Deliver stable repo.
 Archive milestones repo.
 Archive stable products.
 Deliver stable products.
 Archive milestones products.

If script execution is ok:

  • Tag the master branches.
  • Create maintenance branches.
  • Increment version on master branches then commit it.
  • Increment version to the next maintenance version then commit it.
  • Change hudson configuration of maintenance builds to build the new one.

Simultaneous Release

Simultaneous Release migration

  • Update target platform (.target)
  • Add the new plaform profile in root pom.xml
  • Change the default repo use to build in root pom.xml (<eclipse-site> property)

Increment version Process

  • Increment feature version (+ pom.xml)
  • Increment product feature version (+ pom.xml)
  • Increment product version and its dependencies version
  • Increment feature version includes in category.xml
  • Increment documentation version (org.eclipse.koneki.ldt.doc.user/build-help.xml, org/eclipse/koneki/ldt/debug/ui/DocumentationLinksConstants.java and plugin.xml)
  • deploy User guide (wiki)
  • Update Koneki website links to the wiki user guide.

Enable Statistic

Done automatically now by the release script.

  • Move in repo
    • cd releases/stable/${NUM.VERSION}/${repo}
  • Unzip artifacts.jar
    • unzip artifacts.jar
  • Modify artifacts.xml (add p2.statsURI and download.stats property)
<properties size="3">
    <property name="p2.timestamp" value="1339531652273"/>
    <property name="p2.compressed" value="true"/>
    <property name="p2.statsURI" value="http://download.eclipse.org/stats/koneki"/>

....

<artifact classifier="org.eclipse.update.feature" id="org.eclipse.koneki.ldt" version="0.8.0.201206122001">
      <properties size="6">
        <property name="artifact.size" value="20464"/>
        <property name="download.size" value="20464"/>
        <property name="maven-groupId" value="org.eclipse.koneki.ldt-features"/>
        <property name="maven-artifactId" value="org.eclipse.koneki.ldt"/>
        <property name="maven-version" value="0.8.0-SNAPSHOT"/>
        <property name="download.contentType" value="application/zip"/>
        <property name='download.stats' value='org.eclipse.koneki.ldt_0.8.0.201206122001'/>
      </properties>
  • Zip it
    • zip artifacts.jar artifacts.xml
  • remove artifacts.xml
    • rm artifacts.xml

(see : http://wiki.eclipse.org/Equinox_p2_download_stats)