Start versioning and releasing new versions

[rpannek]

As a user it is somewhat difficult to know if the master branch is compatible with my application or if it will break my code, and which version I need to use.

It would be nice if you started releasing versions according to for example http://semver.org/

Github makes it really easy, once you create a tag and push it, it creates a special release page where you can put your release notes, etc. and it creates a tarball and a zip package for it so people who package stuff for distributions have an easier way packaging it.

[gunnarx]

Oh, a waaay old issue here. But it made me associate to the tarball issue and reply to this:

Github makes it really easy, once you create a tag and push it, it creates a special release page where you can put your release notes, etc. and it creates a tarball and a zip package for it so people who package stuff for distributions have an easier way packaging it.

In case you're not aware - I have confirmed (together with Yocto devs, and GitHub support) that the auto-generated tarballs can in fact change -- probably due to some GitHub software update. GitHub have officially answered that they do not guarantee that a checksum of the file is identical forever. The unpacked contents is intact, sure, but the internal tarball format was slightly changed so that MD5/SHA changed. And that's not friendly for Yocto builds or packaging! :-P Just FYI in case you had not heard @rpannek
Only for those automatic tarballs -- it should not happen if you upload a tarball to GitHub.

[rpannek]

I see, interesting, I only am packaging one software like this and at least with that I didn't have any problems yet, bit it is definatelly good to know.

[gunnarx]

Well it was definitely confirmed for the erlang package in question.

A little info here: meta-erlang/meta-erlang#8 My thorough analysis was added to Fedora pastebin but now expired. I probably have it somewhere on disk... But basically it showed that the unpacked contents was still identical, but the tarball anyway had a few small differing bytes in the internal metadata.

It was confirmed since the old erlang recipe had a different MD5 checksum, compared to the new download from GitHub. Since the old .bb file with the stated MD5 had worked in the past we know for sure that the MD5 changed, for that particular tarball version number. Also, the old tarball with the old checksum could be found in our Yocto downloads cache, and compared to the one now hosted by GitHub.

Anyway, there's an old twitter feed showing that this has happened in the past, and GitHub support said what I wrote above.

You won't run into it often - the files are probably cached in some kind of content delivery / caching network. I'm guessing it only happens if something gets stale and is removed from the cache, then re-generated again, and in between GitHub seems to have modified their tar-generation software.

You should know that based on this Ross Burton said he might implement a new QA check in Yocto. I believe that it will then actually warn if recipes are referring to any archive URL in GitHub, not for uploaded tarballs but for auto-generated. Yocto will in other words recommend to use the Git fetcher only, when dealing with GitHub.