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"
| Line 32: | Line 32: | ||
Please note: Our release label is simultaneously also our milestone label. | Please note: Our release label is simultaneously also our milestone label. | ||
| + | |||
| + | == Creating Release Review == | ||
| + | |||
| + | 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 09:59, 16 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
Names and Versions Conventions
Bugzilla
In Bugzilla, we use milestones of the form mYY.MM.
Plugins/Features
While we are in the incubation phase, we use the following version format for plugins and features: 0.mm.ss.qualifier (i.e. 0.1.0.qualifier). The major version number will graduate beyond zero, once we leave incubation. For now, we will always include the qualifier. Note that eventually, we want to get rid of the qualifier for releases. We then have to make sure that we correctly increment service and minor numbers, and after incubation major.
GIT
Our release tag in GIT will be called release-YY.MM. Please note:
- Only the release manager creates tags
- We create no tags for release candidates
Releases
Releases are, by definition, anything that is distributed outside of the Committers of a Project, i.e. a RCP product zip file.
- Release label: Myy.mm (i.e. M12.01).
- Release candidate label: Myy.mmRCx (i.e. M12.01RC1).
Please note: Our release label is simultaneously also our milestone label.
Creating Release Review
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.