Versions Compared

Old Version 26

changes.mady.by.user Unknown User (jamesenglish)

Saved on

compared with

New Version 27

changes.mady.by.user Unknown User (jamesenglish)

Saved on

Key

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

...

Why is GPL (and similar) unacceptable?

In addition, the Apache Software Foundation has a good explanation of why they are also forced to avoid GPL-based (copyleft) licenses because of its one-way compatibility with Apache License 2.0:

"This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. 

We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. We want to honor their license. Unless GPLv3 licensors relax this interpretation of their own license regarding linking, our licensing philosophies are fundamentally incompatible. This is an identical issue for both GPLv2 and GPLv3."

While SimplyE is released under Apache licensing, the same issues exist between BSD licenses and GPL-based licenses.

Database

schema changes

Schema Changes

Database schema changes will be done only on major revisions to the source; this is when the version number takes the form x.0 (e.g. 2.0). When making patches which cause schema changes, it is necessary to update all of the relevant SQL/migration files with your sequences, tables, views etc. 

...

Documentation Contributions

All new features require documentation before they will be accepted. You may send us code before documentation is completed, but we will be unable to accept that code into SimplyEe until it is properly documented. Bug fixes may not require documentation, unless they somehow make a modification which changes how SimplyE functions

  • For Database migrations/management, we use FlywayDB
    • The migration scripts are available in the dspace-api source code under the org.dspace.storage.rdbms.sqlmigration package: https://github.com/DSpace/DSpace/tree/master/dspace-api/src/main/resources/org/dspace/storage/rdbms/sqlmigration
    • Each new migration script should be named "V[version]_[date]__[description].sql", where [version] is the DSpace version supporting this change, [date] is the date of the change, and [description] includes the associated ticket number and brief description of the migration. For example: "V5.0_2014.09.26__DS-1582_Metadata_For_All_Objects.sql".
  • If your database migration adds new sequences, then you should also be sure to update the update-sequences script at:
    • [dspace-src]/dspace/etc/[db-type]/update-sequences.sql
    • At this time, this updated-sequences script is maintained outside of the database migrations as it is useful to run manually after large restorations, etc.

Patching multiple branches 

When you patch the same issue in multiple branches, database changes require special attention.  This advice applies to both schema changes and content changes.

  • FlywayDB migrations are cumulative.  You should depend on changes that you made in the earliest affected branch to be available in later branches, and only do further migrations in later branches if additional changes are needed.
  • When patching a branch earlier than 5_x, you will need to provide an SQL script or a tool to be run manually.  5_x and later patches should still depend on these manual updates, and you should document the need to run them before allowing automatic migrations to run.
  • If the schema was already changed between branches, and those changes affect the same tables that you are updating, depend also on the existing upgrade process to make those changes for you.  For example:  if you make database changes to table T in branch X, and the upgrade from X to Y changes the schema for T, you don't need to rewrite your changes for branch Y because the upgrade already took care of that difference.

Documentation Contributions

All new features require documentation before they will be accepted. You may send us code before documentation is completed, but we will be unable to accept that code into DSpace until it is properly documented. Bug fixes may not require documentation, unless they somehow make a modification which changes how DSpace functions.

All documentation is now built in a special section of the Wiki at DSpace Documentation. Therefore, the best way to send us Documentation is to actually create a new page(s) in this DSpace Wiki. You should link these Wiki page(s) to your issue in our DSpace Issue Tracker. We'll move them over into the official DSpace Documentationarea once you code has been accepted.