Increasing the size of VERSION in tabular status output

[Rick Harding]

15 seems a bit large. James, it'd be interesting to get a screenshot of a
full openstack with the messages/etc in place to see how it's sizing up in
a large complex deploy utilizing the feature fully when rc1 cuts with the
change.

Thanks

On Mon, Sep 19, 2016 at 7:23 PM Tim Penhey <tim.penhey at canonical.com> wrote:

> 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
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160920/2ce8e212/attachment.html>