-
Notifications
You must be signed in to change notification settings - Fork 118
Policies
The supported operating systems are: CentOS Ubuntu
In order to call these platforms supported we need to test to be running a CI environment for each of these OSes. Should we be restricting our officially supported OSes for this development cycle to only the ones we need?
The supported php version is: 5.3.x. Drupal 7 requires at least PHP 5.3.x so I feel comfortable asking that all of our users have this version. New Features Policy
All new features ranging from API changes to additional tools require an email be sent to the developers mailing list for discussion. If people are unable to come up with a consensus on the approach then the roadmap meeting will make the final decision.
Proposal documents should address:
- What - Describe what the new feature is.
- Why - Why you think it should be developed and/or what problem is it solving?
- Where – Where should the feature go.
- Upgrade – Update requirements and recommendations.
Old code should be marked as deprecated but will remain in the API until the next release giving people time to upgrade.
Users should update between all minor version for security and performance fixes. Users should only be using releases. Code that is pulled from the head of GIT should be considered experimental and never used in a live repository.
Active development will only be done on the latest supported version of drupal but bugfixes and security fixes will be back ported to the last-1 version of drupal. ??
Interface breakage can only happen during major version changes. If new interfaces are introduced then the old interface should be marked deprecated and all code in islandora should be ported to the new interface. Deprecated interfaces will be removed during major releases.
Testing is a critical part of Islandora7 and it is being addressed at every level of the development. Islandora is being split into different levels with the lowest level being the api and core. Each level has different requirements and policies. The api and core require multiple use cases, appropriate tests, peer sign-off. At higher levels patches will only need 1 use case and appropriate tests. On top of that all code is reviewed to get accepted to the master repositories.
Peer review is the process were developers must review other code. In critical sections, code will need a second persons sign off before being accepted. Peer reviews helps on all levels. The developers are more careful because they are being watched, the reviewer helps to find bugs and design problems and they all share knowledge.
Unit testing will be used to test classes and functional testing will be used to test integration. The tests should be developed as glass box test meaning that you can see what the code should do so you should be able to test all code paths.
Most bugs are at a design level even before coding starts. To reduce design bugs features must be discussed, use cases from multiple angles must be created and tests for the use cases must be created even before code is developed.
Islandora uses GIT as it’s distributed version control system and is hosted on github. The standard development practise is to fork islandora GIT repositories to your own account for development.
Submitting code to Islandora requires publishing your changes and send a pull request to the release manager. All code will be peer reviewed by the release manager. Code being submitted to islandora core must be peer reviewed and signed off by another developer.
Feature freeze, tagging, etc
You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups