What does the * (asterisk) indicate in the Working Version dropdown

Comments

4 comments

  • Avatar
    Nils Bier

    Hi Mary,

    the asterisk marks the currently published version. E.g. if you've published version 2.1, this version gets the asterisk in the working version drop-down.

    I'll update our docs with this information.

    Cheers,
    Nils

    0
    Comment actions Permalink
  • Avatar
    Mary Anthony

    Ah, interesting, so if I see this on a version that version was the last to be published? So, I if I had version 1.0, 2.0, 3.0, then for one one page the asterisk may be on version 2.0 and for another page the asterisk might be on version 3.0?  

    You know, Currently Published is kind of redundant.  Not to mention is there ever likely to be a Past Published or a Future Published edition?  Why don't y'all just call it Published?

    0
    Comment actions Permalink
  • Avatar
    Nils Bier

    Hi Mary,

    you are right, we have to think about the "Currently Published" naming, as it also makes not much sense when publishing to several new - or existing spaces.
    As it is currently not possible to publish single pages, the asterisk is always set on the same version in the whole space. Or when would you expect to have the asterisk on different versions?

    Cheers,Nils

     

    0
    Comment actions Permalink
  • Avatar
    Mary Anthony

    Nils,

    Interesting, I didn't realize that Currently Published applied across all pages in a space regardless of whether the page *actually changed* when last it was published.

    Ok, so think of a version like a branch.  In a branch I might change 3 files and push that branch up to a master.  Pushing = publish in ScrollVersions.  If I diff'd two branches I would expect to see only the files that actually contained difference / or that were remove / or that were added by me or anyone else.  In fact, Git would only push those 3 files which makes sense to me because that's all that changed.

    In ScrollVersions appears to not be doing an efficient publish. So, suppose I have in BITBUCKETM/1.0 5 files. And I do the following:

    A -> unversioned (or unchanged in 1.0)
    B -> added in 1.0
    C -> Edited in 1.0
    D -> deleted in 1.0
    E -> unversioned (or unchanged in 1.0)

    Then I publish BITBUCKETM/1.0 to a space.  When I look at the pages, I'd expect to see this:

    A  
    B  1.0*
    C  1.0*
    D  -> This case is the odd man out. I want to be able to view the page tree by "version." So, I wouldn't expect to see this file in 1.0 of my page tree.

    Though, overall, I find the whole idea of showing the versioning at the page level just cognitively  the wrong approach.  I've not seen this in any version control system I've ever worked in and I don't find it beneficial with this one.  I want to see the state of affairs of the whole tree (directory) by version (branch).  If I switch the tree view, then the pages would change.  Here, I change the page version and the tree view changes.  

    If I want to drill down into a particular version of a page to see when it last went out, this is something I would do rarely and only when I'm explicitly diff'ing or comparing versions.  ScrollVersions brings this "diff" information front and center and constant in the UI. It makes the UX really cognitively overloaded.

    Let me state. I'm used to working in repositories both for documentation files and code files. Since the start of my career over 20 years ago (RCS anyone?), I have never not version controlled my documentation source files.  Unfortunately, it is still not uncommon in even large firms to have documentation teams that don't version control their files.  

    Still, having worked with many writers and writing teams introducing and using version controlled documentation files, there is a learning curve and a continual battle to overcome writers' misunderstanding of version control.  It strikes me that a lot of what I am seeing in ScrollVersions plugin is this weirdo mashup of version controlling documentation files designed without a solid understanding of version control as it relates to documentation management.  Course, I'm sure, Confluence throws its own weird twist into the mix so could be I misunderstand myself the limitations imposed by the plugin's host application.

     

    0
    Comment actions Permalink

Please sign in to leave a comment.

Powered by Zendesk