<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 2 September 2016 at 00:46, Leo Arias <span dir="ltr"><<a target="_blank" href="mailto:leo.arias@canonical.com">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><div>This is what <a href="https://bugs.launchpad.net/snapcraft/+bug/1594794">https://bugs.launchpad.net/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><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
When we add the snapcraft.yaml, I suspect that the version field will be<br>
forgotten often, and it will not be in sync.<br></blockquote><div><br></div><div>Especially when juggling multiple release branches, which differ only by the version number.<br> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
However, there are a few issues with this. First, launchpad would need a<br>
new text field to fill the version. And then what would you write in<br>
that field? I see problems if you write a static string and if you write<br>
a command to be appended to the snapcraft run.<br>
<br>
Also, it's not always straight-forward to get the version from the code.<br>
Some projects store it in multiple statements, like major=2; minor=1;<br>
patch=3; Transforming that into "v2.1.3" results in a script that's not<br>
so nice.<br>
<br>
Now, I can see it working at least for the snaps I'm building using<br>
travis and docker. I can get the sha1 when building from master, or the<br>
name of tag when there is one, and use that as the version. I would love<br>
that.<br>
<br>
We could make that snapcraft --snap-version=$(git rev-parse HEAD) just<br>
overwrites the version field, useful immediately for people not using<br>
launchpad.<br>
<br>
pura vida<br>
<br clear="all"><br></blockquote></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>