eZ Publish Community Project - Release policy


Published on

This document presents the Release Policy for eZ Publish Community Project, Open-source Content Management System, based on PHP, backed by eZ Systems, the creators of eZ Publish.

Meet the eZ Publish Community at : http://share.ez.no

Published in: Technology, News & Politics
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

eZ Publish Community Project - Release policy

  1. 1. eZ Publish Community Project Board Release policy for eZ Publish Community Projecthttp://share.ez.no/blogs/community-project-boardJune 01, 2011 1
  2. 2. The eZ Publish Community Project Board Robin Nicolas Muilwijk Pastorino h"p://share.ez.no/p/10838 h"p://share.ez.no/p/9804 Ole Marius Andrew Smestad Duck h"p://share.ez.no/p/9710 h"p://share.ez.no/p/10567 Gilles Gaetano Guirand Giunta h"p://share.ez.no/p/90262 h"p://share.ez.no/p/11248eZ Publish Community Project Board 2
  3. 3. Open process, continuous improvementThe Community Project Board had proposed a Release Policy for eZPublish Community Project. This went through a RFC, on whichfeedback was collected : http://bit.ly/ezcp-rfc. The version of theRelease policy presented here incorporates the feedback received.Improvement has to be a continuous process, baked in openness &transparency, so will feedback collection be. The version presentedhere is not meant to be written in stone in a definitive fashion : itshould adapt to the new needs, constraints that we discover whilstusing and participating to the eZ Publish Community Project. Pleasecontinue sharing, exchanging your thoughts :• http://share.ez.no/p/111598 (“Direct contact”)• http://share.ez.no/blogs/community-project-boardeZ Publish Community Project Board 3
  4. 4. The Release Policy answers these questionsHow can an increasing innovation level be supported ?How is full migration-ability between eZ CP and Enterprise Editionpreserved ?How do we make sure it does not add barriers to participation ?How often should eZ Community Project be released ?How can this Release Policy smoothly work together with the existingheartbeat (releases every 6 months for Enterprise Edition) ?How can the management load be kept low (merges, branchings, etc) ?eZ Publish Community Project Board 4
  5. 5. Final policy
  6. 6. Proposed solution - Release policy For eZ Publish Community Project(Details on the next slide) eZ Publish Community Project Board 6
  7. 7. Proposed solution - Release policyFor eZ Publish Community ProjectWorking together Both eZ Community and eZ Engineering are working on the same, single repository for the kernel, on http://github.com/ezsystems/ezpublish. Development is always done on the master branch (note : your pull-requests may come from a dedicated branch in your fork. This is recommended). During the last two months of the heartbeat cycle (the 6 months long Enterprise Edition development cycle), certification and stabilization is done in a branch dedicated to this purpose. The benefit is that development can continue undisturbed on the master branch. Any large feature (e.g.: replacing the template engine) will warrant a separate feature-branch, and must be approved by the Board. The community board is responsible for overseeing that builds are done in a manner and frequency as desired. The board can delegate this duty to a “deputy” or task force.Build scheme Monthly builds will be proposed every month. Nightly builds will be proposed in a near future, purely for testing purposes. This naturally implies a variable stability & reliability level.eZ Publish Community Project Board 7
  8. 8. Proposed solution - Release policyFor eZ Publish Community ProjectNaming scheme The monthly builds names will follow this <yyyy>.<m> naming scheme. As an example, the build released in May 2011 was named 2011.5.Version matching with Enterprise Edition A version map between eZ Publish Community Project and Enterprise Edition will be provided and updated upon every eZ Publish CP build. This will help you keep flexibility in migrating from one to another by guiding your CP version choice when starting a new project.Documentation The documentation for every build should at least contain : • A change-log, listing all fixed bugs and implemented enhancements, • Upgrade documentation, from the previous version to the new one, • Release notes (further incorporated in the documentation on doc.ez.no) about the new features or changes to existing ones.eZ Publish Community Project Board 8
  9. 9. Proposed solution - Release policyFor eZ Publish Community ProjectGuidance on participation Practical guidelines, How-tos and Resources are provided here http://share.ez.no/about/get-involved/ develop including : • A tutorial on how to use Git/Github : http://share.ez.no/learn/ez-publish/how-to-contribute-to-ez-publish-using-git • Coding standards (under public review :http://share.ez.no/blogs/bertrand-dunogier/the-ez-coding-standards-need-you) • Guidance on bug reporting • Guidance on feature proposal (ongoing) • Description of the ideal content of a pull-request (ongoing)eZ Publish Community Project Board 9