Files & filenames for different LO versions

[jeanweber]

David keeps talking about one filename per chapter (or book), even
when the LO version changes (such as from v3.5 to v3.6). This does
match anything in the publishing world, although it may be common for
software (I don't know).

In the publishing world, the v3.5 chapters and books are totally
separate from those for v3.6. They co-exist; one does not replace
another; they would have different ISBN. Therefore they should have
different filenames. This is logical from a human POV and allows files
to be copied elsewhere (such as to Lulu.com) and retain identifying
information in the filename (example: GS3507-xxxxxxx for Chapter 7 of
Getting Started for LO v3.5).

Updates (revisions) to a chapter FOR THE SAME VERSION of LO would not
need to change filename. These updates are called "versions" in
Alfresco, but they are unrelated to LO versions. Updates would be
things like corrections and additions to a chapter for the SAME
version of LO.

--Jean

[Traduction.BIZ]

Hi Jean,

David keeps talking about one filename per chapter (or book), even
when the LO version changes (such as from v3.5 to v3.6). This does
match anything in the publishing world, although it may be common for
software (I don't know).

In the publishing world, the v3.5 chapters and books are totally
separate from those for v3.6. They co-exist; one does not replace
another; they would have different ISBN. Therefore they should have
different filenames. This is logical from a human POV and allows files
to be copied elsewhere (such as to Lulu.com) and retain identifying
information in the filename (example: GS3507-xxxxxxx for Chapter 7 of
Getting Started for LO v3.5).

Updates (revisions) to a chapter FOR THE SAME VERSION of LO would not
need to change filename. These updates are called "versions" in
Alfresco, but they are unrelated to LO versions. Updates would be
things like corrections and additions to a chapter for the SAME
version of LO.

I see your point about file naming, if you really want to maintain
different versions of each guide (each covering a LibO version) *on an
on-going basis*. If, after the release of LibO v3.6, you really plan
to carry-on maintaining and updating the guides for v3.5 then the kind
of file naming system you describe above is perhaps an inevitable
necessity.

But, AFAIK, in reality, once v3.6 comes out, no more work is done on
v3.5 guides.

The reality of the situation in the documentation team is that there
are pretty few regular contributors.

So does it make more sense just to focus on each current version only?

Certainly, in the Alfresco versioning system, you can still provide
links to the past versions of documents that equated to a guide
covering a past version of LibO. So it's not like a guide for that
version is no longer available.

One of the things I had in mind when I started the "Alfresco
brainstorming" thread was to simplify the docs team's work as much as
possible, with pragmatism and realism. My feeling was that, by
simplifying the contributor's work and by reducing the workload as
much as possible, the docs team could possibly produce more new
material - notably material that is not currently existing or
finished, such as Base coverage and context-specific tutorials and
guides.

These are, of course, just thoughts offered up for consideration.

[Dennis_E_Hamilton]

It's also an inevitable necessity when users send in comments and identify defects in the version they happen to have in their hands. It's difficult enough to have them provide the information. If there is high friction in being able to know what it is they are reporting about so it can be identified in a report, all that is left for the user is frustration and disdain.

- Dennis

PS: I notice in this discussion that there is increasing offering of possible fixes and configuration features in Alfresco, along with need for disciplined use. This bottom-up complexification/instant-design is not necessarily a good direction to take. It might be good to step back and identify the essential requirements with regard to affordability for users and authors, then see how to satisfy those as naturally as practicable [;<).