Versions Compared

Old Version 24

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 25

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Since no one has volunteered as 1.7 Release Coordinator, we could release 1.7.0 based on which features/fixes are ready & documented and have been deemed "acceptable" by the DSpace Committer Group.
  • In this way the DSpace Committers Group would act as the "Release Coordinators"
    • Additional "coordination" would happen amongst various ad-hoc "feature teams" (of interested developers). Those teams would have to work to meet the required schedule in order to get their proposed feature(s) into 1.7.0.
  • However, a lack of a single Release Coordinator may require us all to follow more strict code committing "rules". These rules are here to keep us from stepping on each others' toes, and help us to stay on a tighter release schedule.

Proposed 1.7.0 Code Committing Rules:

  1. No incomplete features in "Trunk", ever. If you are in-progress on a feature, create an SVN sandbox or branch area to work on it, and pull it over to Trunk once it has been completed and is ready for testing & release. (This will hopefully help us to avoid encountering a situation where we need to revert a large, unfinished patch at the last moment.)
    • Modules which do not reside in DSpace "Trunk" should also follow this rule. If there is major rework to be done on a module, create a "branch" to do that work and migrate it back to the Module's Trunk once it is ready for release.
  2. All new features must have documentation before committing to Trunk. If a feature has no documentation, it should not be committed to Trunk until there is some minimal documentation (minimal documentation includes documenting all configuration options). This will help us all ensure that Documentation is ready by the time we get to 1.7.0 RC1, and hopefully lessen the time that any one person has to spend cleaning up or rewriting documentation.

...

Panel

NOTE: The list of new 1.7.0 features has not been finalized. The features listed below may or may not make it into the final 1.7.0 release. Features will only be included if they are ready, stable and documented before the 1.7.0 Feature Freeze date listed above.

Potential 1.7.0 New Features (very tentative):

  • CGIProposal (Richard Rodgers/MIT), based on the Item type based submission patch built by Robin Taylor – would allow for type-based submission processes (e.g. Theses/Dissertations could have different submission steps than articles/papers).
  • CurationTaskProposal (Richard Rodgers/MIT)
  • AipBackupRestorePrototype (Tim Donohue/DuraSpace) – would allow for a more complete backup of DSpace into METS-based Archival Information Packages (AIPs). These AIPs could also be used to migrate DSpace content (Communities/Collections/Items) from one system to another.
  • SWORD Client for DSpace? (Robin Taylor) – would allow DSpace to push/submit content to other SWORD enabled repositories
  • Rewrite of Creative Commons licensing (MIT) – would improve upon the features of the current CC licensing submission step
  • Possibly one or more of the Google Summer of Code 2010 projects (if they are ready/stable enough for release)

...