> 3. major version (numeric like 3)
>
> 4. minor version (numeric like 2
>
> 5. revision. (numeric like 5)
>
> This makes a document version of 3.2.5
Not sure we actually need three-step versioning - just x.y should be
enough in most (all?) cases. Or?
> 6. content applies to a PostgreSQL version. (varchar) (like
> "all pg versions", "8.x","7.x"
Wouldn't it be better to have a linked table for this, and just a
checkbox list where you can check each major version that applies? That
will make it a lot easier to do filtering on it in the view (so you can
have an option on pgdn to say "i only want to look at stuff that applies
to 8.1").
Keeping this kind of data in a varchar field leads to lots of different
ways of writing (some write 8, some write 8.x some write 8.* etc etc),
and it's harder to process in a reasonable way.
> 9. status (varchar) (E for editing for published, R for rejected)
Do we need to keep rejected ones at all?
> Do we need more information about a PGDN content? Please let
> me know what you think.
How does this scheme deal with multiple versions?
Say I (not trustworthy, remember!) cerate a document. Then Dave approves
it for publishing. Then I edit it. At this ponit, the old version should
be visible on the site. Then Dave approves the new version, at which
point the old one should go away (or be kept in version history,
probably) and the new one should be published.
//Magnus