Increasing the size of VERSION in tabular status output

Tim Penhey tim.penhey at canonical.com
Mon Sep 19 23:23:38 UTC 2016


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 <john at arbash-meinel.com
> <mailto:john at 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.lutostanski at canonical.com
>     <mailto:gregory.lutostanski at 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.page at ubuntu.com <mailto:james.page at 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 at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>             Modify settings or unsubscribe at:
>             https://lists.ubuntu.com/mailman/listinfo/juju
>
>
>
>         --
>         Juju mailing list
>         Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>         Modify settings or unsubscribe at:
>         https://lists.ubuntu.com/mailman/listinfo/juju
>
>     --
>     Juju mailing list
>     Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju
>
>
>



More information about the Juju mailing list