<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 2 September 2016 at 15:01, Stuart Bishop <span dir="ltr"><<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 2 September 2016 at 00:46, Leo Arias <span dir="ltr"><<a href="mailto:leo.arias@canonical.com" target="_blank">leo.arias@canonical.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">This is a pain point for me too. Most upstreams store the version number<br>
in only one place, because editing more than one for every tagged<br>
release is too boring.<br></blockquote><div><br></div></span><div>This is what <a href="https://bugs.launchpad.net/snapcraft/+bug/1594794" target="_blank">https://bugs.launchpad.net/<wbr>snapcraft/+bug/1594794</a> is about.<br><br></div><div>The plugin can extract a version number in many cases (and plugins could be added that just do this - eg. pull the version from debian/changelog or git tags | grep release | naturalsort | tail -1 or run staging/usr/bin/foo --version or whatever). So a particular part might know its version, and we could declare which part's version is used for the snap. No need to specify anything on the command line, and it would work with Launchpad without extra work.<br></div></div></div></div></blockquote><div><br></div><div>(Or if that is too complicated, just a command that is run at the end of staging or at the start of priming to generate the version number) <br></div></div><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Stuart Bishop <<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>></div>
</div></div>