Yesterday we changed the limit to 15 from 7.

Tim

On 20/09/16 04:41, Rick Harding wrote:
The primary trouble is that we really want to enforce a limit so that
there's room for the arbitrary text at the end of the same line. I think
we could try 10. I do think we need that hard cutoff. If you need to see
the full value going to the json/yaml format output should display the
full value.

Thanks for the feedback. As it's new it's great to see folks trying it
and bringing up the issues that get hit.

Rick

On Mon, Sep 19, 2016 at 12:04 PM John Meinel <j...@arbash-meinel.com
<mailto:j...@arbash-meinel.com>> wrote:

    I'm not sure if the unicode ellipsis would cause table alignment
    issues depending on your terminal and font. We could consider it as
    it does give quite a few characters back. The longest I can come up
    with that doesn't feel just gratuitous is 15
    10.10.10alpha10
    But that might be going to far. I do believe the goal was to funnel
    people to not giving "postgresql-9.8.0-ia32-icc" sort of version
    strings. But it should be useful. 10 characters does seem pretty
    good and doesn't cause us to wrap too often.
    1.2.3beta4
    Fits in 10, but anything that has 2 digits anywhere would end up
    wrapping. It feels a bit odd to force people into 1.2.3b4 though it
    does convey the same information it makes you use a string that may
    not match the actual upstream nomenclature.

    I guess I could be convinced up to 15 characters but 11 might be an
    alternate if we really want people to share the line width but still
    allow matching upstream version strings.

    John
    =:->


    On Sep 19, 2016 19:13, "Gregory Lutostanski"
    <gregory.lutostan...@canonical.com
    <mailto:gregory.lutostan...@canonical.com>> wrote:

        Perhaps also using the utf-8 ellipsis (…) would save some
        characters as well.

        --Greg

        On Mon, Sep 19, 2016 at 10:09 AM, James Page
        <james.p...@ubuntu.com <mailto:james.p...@ubuntu.com>> wrote:

            Hi All

            We've been experimenting with the new
            application-version-set feature in Juju 2.0 in the OpenStack
            charms team; it provides a much needed way for a charm to
            indicate which version of an OpenStack component is deployed
            at any given point in time.

            We've come up with an approach that either use the upstream
            version of the principle component being deployed, falling
            back to the codename for an OpenStack release - for
            deployment from source or prior to the packages being
            installed for example.

            However, we're finding that 7 chars is a bit limiting in the
            default tabular status output - for example:

              9.0.0~b3 (truncates to 9.0....)
              icehouse (truncates to iceh...)

            Could this field be expandable on demand? I think our
            longest example would currently be:

              13.0.0~rc1 (10 chars)

            Cheers

            James

            --
            Juju mailing list
            Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com>
            Modify settings or unsubscribe at:
            https://lists.ubuntu.com/mailman/listinfo/juju



        --
        Juju mailing list
        Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com>
        Modify settings or unsubscribe at:
        https://lists.ubuntu.com/mailman/listinfo/juju

    --
    Juju mailing list
    Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com>
    Modify settings or unsubscribe at:
    https://lists.ubuntu.com/mailman/listinfo/juju




--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Reply via email to