Nearly all openEHR specifications are online in their latest form at
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html
Don't bother looking at the "in-development" ones - they have not gone
up yet; the XML-schema, UML and terminology are being updated to conform.
All feedback welcome; these are very close to the final versions for
openEHR Release 1.0.1
- thomas
Hi!
Nearly all openEHR specifications are online in their latest form at
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.htmlAll feedback welcome; these are very close to the final versions for
openEHR Release 1.0.1
The versioning is a bit confusing:
- In the last quoted sentence above 1.0.1
- In the link above 1.1
- The header of the linked page "openEHR Specification Project Release
1.0.1 Document Road Map"
- The "UML computable form of model" linked from the roadmap says "The
models shown here are are derived from the official openEHR
Release-1.1 candidate (contains a small number of changes with respect
to Release-1.0. PDF specifications)."
-Under http://svn.openehr.org/specification/BRANCHES/ there are only
1.0 and 1.1 no 1.0.1
Are there 1.1 documents and artifacts being worked on simultaneously
as the final release of 1.0.1 or are the as authors confused as I am?
Another (partly unrelated) confusing thing is that the PDFs sometimes
get updated content during development without having document
numbers, dates or change history adjusted.If at least the date was
changed it would be a lot easier to check if documents printed on
paper are up to date or not.
Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/
Erik Sundvall schreef:
Hi!
Nearly all openEHR specifications are online in their latest form at
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.htmlAll feedback welcome; these are very close to the final versions for
openEHR Release 1.0.1
I agree with Erik. (say this to make the matter more urgent) (confusing
versions)
But, besides this, I am glad the documentation project reaches its final
version release. it gives me as developer a steady target.
Bert
Erik Sundvall wrote:
Hi!
Nearly all openEHR specifications are online in their latest form at
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.htmlAll feedback welcome; these are very close to the final versions for
openEHR Release 1.0.1
The versioning is a bit confusing:
- In the last quoted sentence above 1.0.1
- In the link above 1.1
yes, this has been there for 12 months - it was an error when I created
the branch (should have been 1.0.1). The only reason I have not changed
it is that I am not sure how well Subversion will handle such a rename -
my concern is that it will cause a massive copy....does anyone happen to
know? Rename of a directory is an option in Subversion of course, but my
impression is that it doesn't work the way it should - it seems to do a
huge copy kind of action....I should run some tests I guess
- The header of the linked page "openEHR Specification Project Release
1.0.1 Document Road Map"
- The "UML computable form of model" linked from the roadmap says "The
models shown here are are derived from the official openEHR
Release-1.1 candidate (contains a small number of changes with respect
to Release-1.0. PDF specifications)."
-Under http://svn.openehr.org/specification/BRANCHES/ there are only
1.0 and 1.1 no 1.0.1
yes - so to be clear - the next release is Release 1.0.1 - the '1.1'
thing is just an error in the Subversion repository branch name which I
have not been game to fix for the above reason.
Are there 1.1 documents and artifacts being worked on simultaneously
as the final release of 1.0.1 or are the as authors confused as I am?Another (partly unrelated) confusing thing is that the PDFs sometimes
get updated content during development without having document
numbers, dates or change history adjusted.If at least the date was
changed it would be a lot easier to check if documents printed on
paper are up to date or not.
We are pretty careful with this, although I know there have been
exceptions; the document dates always get changed; the version number
does not (otherwise we would have endless versions just due to the
review process); the change history is almost always updated unless the
change is a typo or similar. We have used a new style of front page to
make this information easier to see. Hope that helps somewhat.
- thomas
Hi!
Nice that the 1.0.1 is coming closer to release. Good work!
> - The "UML computable form of model" linked from the roadmap says "The
> models shown here are are derived from the official openEHR
> Release-1.1 candidate (contains a small number of changes with respect
> to Release-1.0. PDF specifications)."
I noticed that the error above comes from the fact that the "UML
computable form of model" link on the page...
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html
...points to...
http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml.html
...on TRUNK instead of the release branch as the other documents on the page.
It should point to:
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/computable/UML/uml.html
that containts the less confusing text 
The subversion error probably needs to be fixed before some future 1.1
release anyway so why not fix it before the 1.0.1 release instead.
That may save some confusion in the long run.
I guess the only alternative would be to skip 1.0.1 and call the
imminent release 1.1 instead, but that will probably be a worse
solution crating even more confusion.
Best regards,
Erik Sundvall
http://www.imt.liu.se/~erisu/
the branch (should have been 1.0.1). The only reason I have not changed
it is that I am not sure how well Subversion will handle such a rename -
my concern is that it will cause a massive copy....does anyone happen to
know? Rename of a directory is an option in Subversion of course, but my
impression is that it doesn't work the way it should - it seems to do a
huge copy kind of action....I should run some tests I guess
A rename operation will appear to copy/delete every item
at the client end - however, at the server end subversion is
very smart and effectively performs the operation without
actually copying any of the data. It uses the same
technique that Subversion uses for performing
tagging/branching (which is a server 'copy' operation that
doesn't actually duplicate the data on the server). So there
is no problems with the repository growing. The only gotcha
is its behaviour if there are modified descendants of the
directory you are renaming. It may just be the clients but
I seem to remember them not being handled so well - so
just make sure everything is committed before renaming.
Andrew
Andrew Patterson wrote:
the branch (should have been 1.0.1). The only reason I have not changed
it is that I am not sure how well Subversion will handle such a rename -
my concern is that it will cause a massive copy....does anyone happen to
know? Rename of a directory is an option in Subversion of course, but my
impression is that it doesn't work the way it should - it seems to do a
huge copy kind of action....I should run some tests I guess
A rename operation will appear to copy/delete every item
at the client end - however, at the server end subversion is
very smart and effectively performs the operation without
actually copying any of the data. It uses the same
technique that Subversion uses for performing
tagging/branching (which is a server 'copy' operation that
doesn't actually duplicate the data on the server). So there
is no problems with the repository growing. The only gotcha
is its behaviour if there are modified descendants of the
directory you are renaming. It may just be the clients but
I seem to remember them not being handled so well - so
just make sure everything is committed before renaming.
Hm. I wonder what would happen if I went to the server and did a rename
using a command line command there? How would the clients react n their
next 'update'?
- thomas
Thomas Beale schreef:
Andrew Patterson wrote:
the branch (should have been 1.0.1). The only reason I have not changed
it is that I am not sure how well Subversion will handle such a rename -
my concern is that it will cause a massive copy....does anyone happen to
know? Rename of a directory is an option in Subversion of course, but my
impression is that it doesn't work the way it should - it seems to do a
huge copy kind of action....I should run some tests I guess
A rename operation will appear to copy/delete every item
at the client end - however, at the server end subversion is
very smart and effectively performs the operation without
actually copying any of the data. It uses the same
technique that Subversion uses for performing
tagging/branching (which is a server 'copy' operation that
doesn't actually duplicate the data on the server). So there
is no problems with the repository growing. The only gotcha
is its behaviour if there are modified descendants of the
directory you are renaming. It may just be the clients but
I seem to remember them not being handled so well - so
just make sure everything is committed before renaming.
Hm. I wonder what would happen if I went to the server and did a rename
using a command line command there? How would the clients react n their
next 'update'?
My client would create a new directory, as it always does as it gets a
new directory offered.
I will delete the old one manually, no problem.
bert
My client would create a new directory, as it always does as it gets a
new directory offered.
I will delete the old one manually, no problem.
Even better than that, as long as Bert has no local modifications in
his tree, it will delete the old directory for him properly. It will
even retain file histories for all files in the renamed directories
(and the directories themselves - you could check out an
old revision and it will correctly make the old directory). The
subversion directory handling is really quite good.
Andrew
Andrew Patterson wrote:
My client would create a new directory, as it always does as it gets a
new directory offered.
I will delete the old one manually, no problem.
Even better than that, as long as Bert has no local modifications in
his tree, it will delete the old directory for him properly. It will
even retain file histories for all files in the renamed directories
(and the directories themselves - you could check out an
old revision and it will correctly make the old directory). The
subversion directory handling is really quite good.
do you know this for a fact? I retain memories of when it was not so good!
- thomas