Could you please use 'releases' feature on github? about exiv2

[draekko]

Currently releases are available at http://exiv2.org/download.html

[clanmills]

@Systerr Thanks for your comments. As @draekko says, we publish the released code on our website. Exiv2 has been alive and well for 14+ years with the code on svn://dev.exiv2.svn/trunk and tracked our issue with Redmine. With the release of v0.26, we've moved to GitHub and you have the honour of the first issue report. I'm delighted that Ben (draekko) is supporting the project's use of Git. I'm at the bottom of the learning mountain concerning Git, so I'm happy to accept your suggestions about how to make the most of the tools. Happy to discuss here or Skype 'clanmills'

[clanmills]

I don't have sufficient experience with Git to make progress on my own with this issue.

[Systerr]

Thank you for your answer. Looks like link on website was broken when i try to download it. Right now it works fine.
I was try the next day after release. ICC was long waiting feature for me.
At any case releases on github is very useful and it easy to use.
Releases based on tags (that the main advantage of releases, developers can easly see on local env history of project). Also when tag is available it easy to compare tags by itself (containing many commits)
For example to crate a release fro v0.26 you need to checkout the final commit of that version (lloks like that commit was fa449a4)

git checkout fa449a4
git tag 0.26
git push --tags
git checkout master

What we did:

1. checkout the commit by it short hash
2. add tag to that commit (0.26 it that case, but possible to use any text for that,
3. push all tags (in our case we have only one tag)
4. return back to master branch (for next time)
   Next possible to add some release description on "releases" tab and put release to public. Without that release will be marker as "pre release"

Also it possible to drag additional files to release and that files will be available to download.
The source files of release will be shipped by github itself
As example of "releases" you can look the openCV repo https://github.com/opencv/opencv/releases

[clanmills]

Ah, yes. There was a bug on the download button on the website. I discovered other issues with the website and hope they are all cleared up now.

Because I'm new to Git, I'm not too sure what you're telling me. If I grant you write-access to the repos can you tag the release? It is tagged in SVN (r4771). svn://dev.exiv2.org/svn/trunk

I'm using SmartGIT (because I've used SmartSVN every day for the last 10 years). There's a button 'Git-Flow' that brings up a Dialog box. Is this something we should be using?

[Systerr]

Because I'm new to Git, I'm not too sure what you're telling me. If I grant you write-access to the repos can you tag the release?
Yes i can do that.

Sorry i have no idea how to do that on SmartGIT. The command that i provided is a terminal commands. You can open terminal and paste that commands.

For gitflow, yes that should be used.
Gitflow primary is a how to use git (methodology), means how to use git one varian
Useful links
http://nvie.com/posts/a-successful-git-branching-model/ (original idea)
https://www.atlassian.com/git/tutorials/comparing-workflows
https://danielkummer.github.io/git-flow-cheatsheet/ (short version for plugin)

Also sometimes gitflow means git plugin that do i gitflow methodology.

For my case gilflow very useful and allow to do a quick bug fixing and release all features asap (no need to wait when another features will be read, all features isolated and independent)
Git flow means that we have a few branches (master(always stable), develop(should be stable too), feature branches (developers do some work here, not stable, dev only), releases (contain releases, i always skip that branch) and hotfixes))
Let me try to provide useful example here (please not i'm not very familiar with exiv2 codebase and example can be strange)

Example

Repo have master (contains lates released version) and develop (contain the same version of code, because no any new fixed was made). That develeoperOne start to implement new feature (let say that was a improvement of some raw formats support). That developer will create new branch

git checkout develop
git pull
git checkout -b feature/impoveRaw

and start working on that branch and push all code to that branch. At that case that master branch and develop branch have that previous version of code and not affected by that new feature (that not yet stable)
Few days later developerTwo relize that for some reason one of iptc tags was missed on some magic conditions (bug). And start working on that feature.
DeveloperTwo will use develop branch to start own feature (that branch not affected by feature/impoveRaw feature branch).

git checkout develop
git pull
git checkout -b feature/fixOneIPCTTag

Now developerThree want to add some more tests to codebase and started new branch from develop

git checkout develop
git pull
git checkout -b feature/addMoreTests

That time developerTwo finished his bug fix and want to merge it to develop. Hi can do that or some other special engineer can do that.

git checkout develop
git pull
git merge --no-ff feature/fixOneIPCTTag

git merge --no-ff feature/addMoreTests will merge all commits from feature/addMoreTests to develop branch. "--no-ff" means "no fast forward" that will keep history of branch that useful for investigation history in my opinion that options should be default on git
So for now his feature merged to develop branch (not yet on master).

After few hours developerThree also finished more test and merged it to develop branch (that possible with no pain, git good it resolving merging conflicts, especially the fixes was made on different parts of codebase (that no any hand work required)).

git checkout develop
git pull
git merge --no-ff feature/addMoreTests

Now develop branch contains "fixOneIPCTTag" and "addMoreTests" feature. But developerOne inform teams that he will be busy next few week and paused work on "impoveRaw" feature.
Then other team have no any reason to wait that time and want to release "fixOneIPCTTag" and "addMoreTests" features right now.

git checkout master
git pull
git merge --no-ff develop
git tag 0.26.1
git push --tags

And now we have version 0.26.1 and released new version of exiv2 and make some peoples happy that bug resolved and released, no any reason to wait for 0.27 for that bug

Sorry for my bad english and so long post.

[clanmills]

Thanks. I'm on a learning curve. I have enabled "Git-Flow" and added a branch called "tags/" for revisions.

You don't need to know anything about SmartGIT, it's a GUI for git terminal commands. I've ordered the "Git Pro" book and it'll be here this afternoon. I started learning git in 2013 with intention of using it for Exiv2 v0.26. However, in 2014, I moved house from Silicon Valley to England and stuck with SVN for v0.26. I made this drawing in 2013 to explain pull/push/merge etc to myself.GitOrientation.pdf
)

Thank you for your help with all those commands. I'll grant you write access to our repository. I'll try your commands when the Git Pro Book arrives.

[clanmills]

@Systerr: I think I've been able to create the tag of your dreams with some help from my son.

$ git tag v0.26 fa449a4d2c58d63f0d75ff259f25683a98a44630
$ git push --tags

Can you confirm that you're happy with this and I will close the issue.

[Systerr]

Yes. Thank you!

[eszlari]

Have you reconsidered this?

It would be nice, if you could add the official tarballs to Github's release page: https://github.com/Exiv2/exiv2/releases

This would make the URL to the current release permanent (the URL seems to change with new releases) and also provide a safe mirror.

[piponazo]

Hi @eszlari . We are already using the Github releases feature, e.g. Here you would find the latest stable release:

https://github.com/Exiv2/exiv2/releases/tag/v0.27.2

what are you missing exactly ?

[eszlari]

Add the official tarball (https://www.exiv2.org/builds/exiv2-0.27.2-Source.tar.gz) to the release. Now there are only the Github auto-generated tarball provided (obviously with a different checksum).

[clanmills]

@eszlari Would you like to volunteer to be the Exiv2 release engineer?

[eszlari]

I don't know if this is meant to be sarcastic or not, but what is so hard about adding that single file?

[clanmills]

I haven't understood your request. I believe the stuff on https://github.com/Exiv2/exiv2/releases/tag/v0.27.2 is created automatically by GitHub.

The builds on exiv2.org are created by a script on our build server (a mac mini).

With every release of Exiv2 since we moved to GitHub, somebody has emailed about the GitHub release to ask for something to be changed. So, you're wanting something changed about the release process. I would be very happy for you to deal with the GitHub release and take this off my back.

[eszlari]

I haven't understood your request. I believe the stuff on https://github.com/Exiv2/exiv2/releases/tag/v0.27.2 is created automatically by GitHub.

You can upload files by clicking the Edit button:

[clanmills]

So what files do you want there? Only the source bundle from the build server, or the binary builds or what?

I'm not fed up with you. However, I'm fed up with the email that arrives from somebody the day after the release asking for something to tagged, or changed, or something'ed. It's damn hard work getting the release out the door. And the first email to arrive is a complaint about something I've never heard about.

[eszlari]

https://www.exiv2.org/builds/exiv2-0.27.2-Source.tar.gz
SHA256: 2652f56b912711327baff6dc0c90960818211cf7ab79bb5e1eb59320b78d153f

[clanmills]

OK. I'll do that in future. I'm working on Exiv2 v0.27.3 at the moment. RC1 is on track to ship as scheduled on 2020-04-30.

Thank You for your suggestion. And thank you for using Exiv2.

[clanmills]

I've updated our release Checklist:
svn://dev.exiv2.org/svn/team/website/Checklist.txt

[clanmills]

It wasn't as simple as using the edit pane on GitHub. These source "assets" are generated by GitHub. I've update our release procedure again to use $ git tag earlier in the process, then download the asset to replace the one created by our build server. Curiously, they are not identical and I'll have to investigate the difference. The release procedure has been updated: svn://dev.exiv2.org/svn/team/website/Checklist.txt

[eszlari]

Please ignore the tarballs that are created by Github automatically, they are not guaranteed to be deterministic: keybase/client#10800 (comment)

[...] The main purpose of the auto-generated
archives are for someone to download the source from the
website if they don't want to bother with downloading the repository.

It is not meant to be reliable or a way to distribute software releases
and nothing in the software stack is made to try to produce consistent
archives. This is no different from creating a tarball locally and
trying verify it with the hash of the tarball someone created on their
own machine.

The only way to get a known-good checksum for a tarball is to have
upstream (or the packagers) prepare the release and upload the tarball
alongside its checksum. This is true regardless of GitHub. There is a
feature on the site where maintainers can upload their own assets for a
release though clearly not too many people actually use it.

[clanmills]

Good to hear from you, Thanks.

Ah, that's interesting. What's in GitHub's .tar.gz builds and passes the test suite. And it's about the same size as our build server which produces it with CMake/CPack.

However, I thought you wanted the sha256sum of the GitHub tar-ball to be the same as our build server and that's only possible if I accept their's in preference to our buildservers.

[clanmills]

The release appears to be good. I've looked at three things:

615 rmills@rmillsmbp:~/temp/foo $ dirs
drwxr-xr-x  37 rmills  staff   1184  1 May 07:23 exiv2-0.27.3.1-Source/ <-- unzip of our source 
drwxr-xr-x  37 rmills  staff   1184  1 May 07:19 0.27-maintenance/     <-- fresh clone (without .git)
drwxr-xr-x@ 37 rmills  staff   1184 30 Apr 17:02 exiv2-0.27.3-RC1/    <-- unzip of GitHub's tarball
616 rmills@rmillsmbp:~/temp/foo $ 

Then for each, I do:

(cd $foo ; $ find . -type f | sort > ../foo.txt`)

So I have three files:

618 rmills@rmillsmbp:~/temp/foo $ ls -l *.txt
-rw-r--r--  1 rmills  staff  47969  1 May 07:24 0.27-maintenance.txt
-rw-r--r--  1 rmills  staff  47969  1 May 07:25 exiv2-0.27.3-RC1.txt
-rw-r--r--  1 rmills  staff  47969  1 May 07:25 exiv2-0.27.3.1-Source.txt
619 rmills@rmillsmbp:~/temp/foo $ 

Amazingly they are identical. All have 1339 files. All with the same names. A du -k foo on each directory makes them the same size at 118208 exiv2-0.27.3-RC1

I've .tar.gz'ed them:

627 rmills@rmillsmbp:~/temp/foo $ ls -l *.tar.gz
-rw-r--r--  1 rmills  staff  27863968  1 May 07:43 0.27-maintenance.tar.gz
-rw-r--r--  1 rmills  staff  27945311  1 May 07:42 exiv2-0.27.3-RC1.tar.gz
-rw-r--r--  1 rmills  staff  27866372  1 May 07:42 exiv2-0.27.3.1-Source.tar.gz
628 rmills@rmillsmbp:~/temp/foo $ sha256sum *.tar.gz
c8a2d754ef0353c8a70fc3a08daf38777592175f38d40533749782e17ebfa74f  0.27-maintenance.tar.gz
d0f1836721fed4f652abe419db811dc5f8c836482583d0790c353f60d9cbea66  exiv2-0.27.3-RC1.tar.gz
a257a976eb41c874f2ddb21f3f846799dc365d92248b7004c90f33bef9db3e89  exiv2-0.27.3.1-Source.tar.gz
629 rmills@rmillsmbp:~/temp/foo $ 

I've used the Edit button on: https://github.com/Exiv2/exiv2/releases/tag/v0.27.3-RC1 This doesn't enable me to add/remove/change the files.

I've reached the concussion that no further investigation is either possible or necessary.