-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version directory naming #31
Conversation
For compatibility with existing filesystem conventions, implementations MAY use zero-padded version numbers, | ||
with the following restriction: If zero-padded version numbers are used then they MUST start with a zero. For example, | ||
in an implementation that uses five digits the version directory names <code>v00001</code> to <code>v09999</code> are | ||
allowed, <code>v10000</code> is not allowed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not? A regex such as v([\d]+)
would capture the integer value. Is this for sorting purposes? If so, we should mention that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make follow-suit numbering of an inherited filesystem easier. Looking at the last version tells you what the next version number should be - rather than tracking back to the last-version-that-changed-the-number-of-significant-digits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, we do need to mention follow suit. Version numbers should either be all unpadded or all padded to the same length. Or else we need additional rules so that v1, v001 and v00000000001 don't coexist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...people will do that. We have shelfmarks where punctuation and spacing are significant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ahankinson - I included the v0...
requirement for padded following the discussion in #2 (comment)
@neilsjefferies - The following part of the PR does sat the the length must be consistent
All versions MUST use the same naming convention: either a non-padded version number, or a zero-padded version number of consistent length.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would specify "decimal" numbers! And versioning consistency at the object level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on line 206 change "All versions MUST use...." to "All versions of an object MUST use....." to ensure clarity.
@rosy1280 - I agree, will do. |
c6e3291
and the version directory name is constructed by adding the prefix <code>v</code>. | ||
</p> | ||
<p> | ||
It is RECOMMENDED that implementations use version directory names constructed without zero-padding the version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change to MUST/MAY/SHOULD language?
Implementations SHOULD use version directory...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RECOMMENDED is part of RFC2119... we should discuss this on our call (and add to the spec) --> #35
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is acceptable to me - I'm a bit concerned that it limits existing Moab versions to < 999, but unless we significantly change our workflows that's not likely to be a practical problem until long after we can create native OCFL objects.
# Conflicts: # index.html
547c26c
There was a merge conflict when trying to bring this branch to a mergeable state. I am noting that this automatically invalidates the reviews, but there were no changes to the text for this process. Merging under the 'rapid merge' policy. |
First stab at text for version directory naming
Resolves #2