Ticket #51 (closed story: fixed)

Opened 14 years ago

Last modified 13 years ago

Creating new versions of material

Reported by: tarmo Owned by: tarmo
Priority: major Milestone:
Component: generic Version:
Keywords: Cc:
Time planned: Time remaining:
Time spent:

Description (last modified by tarmo) (diff)

With any material the user can decide to make a new version. In he material's front page is a link "create new version", which adds opens the edit form for a new material version, prefilled with current information.

Licencing terms may limit what can be edited (like authors, which you can only append to). Saving options are like in story "User translates content", #38.

Attachments

ResourceIDsAndVersions.jpeg (322.3 KB) - added by tarmo 13 years ago.
Concept map of different versions of a resource, and the references between them

Change History

comment:1 Changed 14 years ago by tarmo

  • Description modified (diff)

comment:2 Changed 14 years ago by jan

I agree with the ideas here, but would emphasize that we should divide between content and structure. In a xml-profile you would typically have the content stored within html-files and such that are referenced in the xml-file (like in LOM content packaging). But the structure of the xml-file is quite different and you should be able to modify the process which the xml-file models.

comment:3 Changed 14 years ago by teemu

  • Priority changed from major to critical

comment:4 Changed 13 years ago by tarmo

  • Priority changed from critical to major
  • Description modified (diff)

Upgraded description to use current concepts.

comment:5 Changed 13 years ago by tarmo

  • Owner changed from anonymous to tarmo
  • Status changed from new to assigned
  • Description modified (diff)

comment:6 Changed 13 years ago by jukka

I have a related worry: Lots of versions from same resource could make a quick mess off search results and other catalog-based searches. Versions that are translations of content should be found with searches, but otherwise we should devise a rule to avoid search results that are essentially the same resource times ten. If title=title, show only newest?

It could even make sense to check and remove older deprecated versions from catalog when new version is available.

comment:7 Changed 13 years ago by tarmo

Well, even the title can change when a new version is created... We'll have to see how people use the system. I'd at least hope that small changes are made during the draft state and after publishing new versions are created when there is some major change to be done. But maybe I'm wrong. It's good to keep this in mind, though, but we can't just automatically keep the newest version, since the revision tree is a tree and can have several branches with very different variations.

Maybe we need some kind of help from the users, like a check box in the style of "This is a small change" as in MediaWiki, which would allow us to determine, whether a new version is a small change, and thus a replacement of the previous one, or whether it's something different.

Or we can just keep the latest version of each author as active. I think we'll need a new state, called "obsolete" or something, for when the same author makes a new version, or when a new "small change" version comes along.

comment:8 Changed 13 years ago by hans

In search results we can display only the latest version in one language (if English is available, then in English, else in language of the latest version). In addition to this result we should display links to other translations and other versions:

5 translations 3 versions

Changed 13 years ago by tarmo

Concept map of different versions of a resource, and the references between them

comment:9 Changed 13 years ago by tarmo

  • Description modified (diff)
  • Summary changed from User modifies content to Creating new versions of material

Changed title

comment:10 Changed 13 years ago by tarmo

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.