Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "RMF/Contributor Guide/Build Process"
< RMF
(→Plugins/Features) |
(Complete revision of release process) |
||
| Line 1: | Line 1: | ||
We're still in the incubator phase - therefore, the release process is still being developed. Here are our guidelines so far: | We're still in the incubator phase - therefore, the release process is still being developed. Here are our guidelines so far: | ||
| − | == The Most Important Stuff == | + | === The Most Important Stuff === |
* Our release manager is [mailto:lukas.ladenberger@formalmind.com Lukas Ladenberger]. Please coordinate with Lukas. | * Our release manager is [mailto:lukas.ladenberger@formalmind.com Lukas Ladenberger]. Please coordinate with Lukas. | ||
| Line 8: | Line 8: | ||
* The only branches on the server are master and develop. All other branches that are mentioned in git-flow are local branches | * The only branches on the server are master and develop. All other branches that are mentioned in git-flow are local branches | ||
| − | == | + | === Glossary === |
| − | + | (17-Jan-2012) There has been a lot of discussion on rmf-dev. Some of the confusion stems from sloppy terminology. Therefore, here a little glossary: | |
| − | + | ; Release : A Release is a super-official artifact that is typically published after reaching a number of milestones and building a few release candidates. A Release of RMF is somewhere in the far future and not yet planned. | |
| + | ; Milestone : A milstone is a well-defined point towards a release. No milestones are yet planned for RMF. | ||
| + | ; Release Candidate : After the last milestone before a release, one ore more release candidates are built. No major features may go into a RC, only bug fixes. | ||
| + | ; Nightly Built : A nightly built is typically generated by an continuous integration system, based on the latest code in the repository and may be instable. It is published, so that daring users can try it out. As we currently don't have a CI system, we don't have nightly builts. | ||
| + | ; Snapshot : Similar to a nightly built, but built on demand from the latest sources and published. | ||
| + | ; Checkpoint : We use the term "Checkpoint" to mark the end of a development iteration. We use a schedule-driven (rather than feature-driven) development process. Checkpoints are created in the Milestone-Field in Bugzilla. At the beginning of a development iteration, all bugs are reviewed by the team and assigned to a checkpoint. | ||
| − | === | + | === Development Process === |
| − | + | For now, we use a schedule-driven, iterative development process. An iteration is 8 weeks long and consists of the following steps: | |
| + | |||
| + | * Review and revise the [[RMF/Roadmap|Roadmap]] | ||
| + | * Review open issues (bugs and feature requests) and decide which issues should be resolved in the upcoming iteration. Those issues will be assigned to the corresponding checkpoint (e.g. c12.03 for the March 2012 checkpoint). | ||
| + | * Developers get busy implementing. | ||
| + | * At the end of the iteration, a snapshot is published, both in the form of a product built and update site (Bonus: once we have a CI system, this is probably just a link to the corresponding nightly built). | ||
| + | * Rinse, repeat. | ||
| + | |||
| + | === Version Numbers === | ||
| + | |||
| + | We have version numbers for: | ||
| + | |||
| + | * Plugins | ||
| + | * Features | ||
| + | * Product | ||
| + | * Project | ||
| + | |||
| + | We have the following rules: | ||
| + | |||
| + | * While in the incubation phase, all major version numbers remain 0. | ||
| + | * While in the incubation phase, we will always generate qualifiers. | ||
| + | * '''Plugins:''' The minor and service numbers are incremented according to the Eclipse version rules. | ||
| + | * '''Features:''' The minor and service numbers are incremented according to the Eclipse version rules. | ||
| + | |||
| + | We have not decided yet what to do about the version number of product and project. One suggestion is: | ||
| + | |||
| + | * Create an "overarching" feature that aggregates all other features (e.g. an SDK Feature). Once such a feature is created, its version number is incremented according to the Eclipse version rules. Use the same version number for the product. | ||
| + | |||
| + | (mj) I don't quite like this, as it feels arbitrary and rather meaningless. OTOH, it would work and is kind of predictable. | ||
| + | |||
| + | Once we leave incubator phase, we will join the Eclipse release train and therefore conform the the relase train requirements. The major version number will graduate beyond zero, once we leave incubation. For now, the plugin and feature name must follow a ''(Incubation)'' mark. | ||
=== GIT === | === GIT === | ||
| − | + | We will tag snapshots as snapshot-yyyymmdd (optionally followed by -hhmm, if more than one a day). Once we have a CI system, we will create corresponding tags starting with nightly-. | |
| − | + | ||
| − | + | If we reach a checkpoint, we create an additional tag checkpoint-yy.mm. While we are in the incubation phase, we will commit the checkpoint code to the master branch. | |
| + | |||
| + | Only the release manager creates tags. | ||
| − | === | + | === Publishing Artifacts === |
| − | + | Snapshots, Nightlies and Checkpoints will be published, both as stand-alone builts and update site builts. We still have to figure out how the version number is constructed, the git tag is appended. Examples: | |
| − | * | + | * pror-0.1.0-snapshot-20120117-incubation-linux-gtk-x86.zip |
| − | * | + | * pror-0.1.0-checkpoint-12.01-incubation-linux-gtk-x86.zip |
| − | + | === Release Reviews === | |
| − | + | '''Note''': This is just for reference, as we won't have official releases any time soon. | |
All official Releases must have a successful Release Review before being made available for download. The purposes of a Release Review are: to summarize the accomplishments of the release, to verify that the IP Policy has been followed and all approvals have been received, to highlight any remaining quality and/or architectural issues, and to verify that the project is continuing to operate according to the Principles and Purposes of Eclipse [http://www.eclipse.org/projects/dev_process/development_process_2011.php#6_3_3_Release_Review]. More information about a Release Review can be found at: [[Development_Resources/HOWTO/Release_Reviews]]. | All official Releases must have a successful Release Review before being made available for download. The purposes of a Release Review are: to summarize the accomplishments of the release, to verify that the IP Policy has been followed and all approvals have been received, to highlight any remaining quality and/or architectural issues, and to verify that the project is continuing to operate according to the Principles and Purposes of Eclipse [http://www.eclipse.org/projects/dev_process/development_process_2011.php#6_3_3_Release_Review]. More information about a Release Review can be found at: [[Development_Resources/HOWTO/Release_Reviews]]. | ||
[[Category:RMF]] | [[Category:RMF]] | ||
Revision as of 07:44, 17 January 2012
We're still in the incubator phase - therefore, the release process is still being developed. Here are our guidelines so far:
Contents
The Most Important Stuff
- Our release manager is Lukas Ladenberger. Please coordinate with Lukas.
- We use the Git Flow Process as our release process
- Important: Never commit to master! (unless you are the release manager). Development takes place on the develop branch)
- The only branches on the server are master and develop. All other branches that are mentioned in git-flow are local branches
Glossary
(17-Jan-2012) There has been a lot of discussion on rmf-dev. Some of the confusion stems from sloppy terminology. Therefore, here a little glossary:
- Release
- A Release is a super-official artifact that is typically published after reaching a number of milestones and building a few release candidates. A Release of RMF is somewhere in the far future and not yet planned.
- Milestone
- A milstone is a well-defined point towards a release. No milestones are yet planned for RMF.
- Release Candidate
- After the last milestone before a release, one ore more release candidates are built. No major features may go into a RC, only bug fixes.
- Nightly Built
- A nightly built is typically generated by an continuous integration system, based on the latest code in the repository and may be instable. It is published, so that daring users can try it out. As we currently don't have a CI system, we don't have nightly builts.
- Snapshot
- Similar to a nightly built, but built on demand from the latest sources and published.
- Checkpoint
- We use the term "Checkpoint" to mark the end of a development iteration. We use a schedule-driven (rather than feature-driven) development process. Checkpoints are created in the Milestone-Field in Bugzilla. At the beginning of a development iteration, all bugs are reviewed by the team and assigned to a checkpoint.
Development Process
For now, we use a schedule-driven, iterative development process. An iteration is 8 weeks long and consists of the following steps:
- Review and revise the Roadmap
- Review open issues (bugs and feature requests) and decide which issues should be resolved in the upcoming iteration. Those issues will be assigned to the corresponding checkpoint (e.g. c12.03 for the March 2012 checkpoint).
- Developers get busy implementing.
- At the end of the iteration, a snapshot is published, both in the form of a product built and update site (Bonus: once we have a CI system, this is probably just a link to the corresponding nightly built).
- Rinse, repeat.
Version Numbers
We have version numbers for:
- Plugins
- Features
- Product
- Project
We have the following rules:
- While in the incubation phase, all major version numbers remain 0.
- While in the incubation phase, we will always generate qualifiers.
- Plugins: The minor and service numbers are incremented according to the Eclipse version rules.
- Features: The minor and service numbers are incremented according to the Eclipse version rules.
We have not decided yet what to do about the version number of product and project. One suggestion is:
- Create an "overarching" feature that aggregates all other features (e.g. an SDK Feature). Once such a feature is created, its version number is incremented according to the Eclipse version rules. Use the same version number for the product.
(mj) I don't quite like this, as it feels arbitrary and rather meaningless. OTOH, it would work and is kind of predictable.
Once we leave incubator phase, we will join the Eclipse release train and therefore conform the the relase train requirements. The major version number will graduate beyond zero, once we leave incubation. For now, the plugin and feature name must follow a (Incubation) mark.
GIT
We will tag snapshots as snapshot-yyyymmdd (optionally followed by -hhmm, if more than one a day). Once we have a CI system, we will create corresponding tags starting with nightly-.
If we reach a checkpoint, we create an additional tag checkpoint-yy.mm. While we are in the incubation phase, we will commit the checkpoint code to the master branch.
Only the release manager creates tags.
Publishing Artifacts
Snapshots, Nightlies and Checkpoints will be published, both as stand-alone builts and update site builts. We still have to figure out how the version number is constructed, the git tag is appended. Examples:
- pror-0.1.0-snapshot-20120117-incubation-linux-gtk-x86.zip
- pror-0.1.0-checkpoint-12.01-incubation-linux-gtk-x86.zip
Release Reviews
Note: This is just for reference, as we won't have official releases any time soon.
All official Releases must have a successful Release Review before being made available for download. The purposes of a Release Review are: to summarize the accomplishments of the release, to verify that the IP Policy has been followed and all approvals have been received, to highlight any remaining quality and/or architectural issues, and to verify that the project is continuing to operate according to the Principles and Purposes of Eclipse [1]. More information about a Release Review can be found at: Development_Resources/HOWTO/Release_Reviews.