search

prati0100 / git-gui

Tcl/Tk based UI for Git. I am currently acting as the project's maintainer.
161 stars 87 forks source link

This is just a question: when is the new release version? #45

Open tasty0tomato opened 3 years ago

tasty0tomato commented 3 years ago

And also when is the 1.0 version and what will be in it.

I find that the "latest" release version was in 2016 and then nothing, so I have this question.

PhilipOakley commented 3 years ago

@tasty0tomato Where were you sourcing your copy from? and how was the version number and date determined?

A copy of he git gui is held and updated within the main Git and Git for Windows projects.

tasty0tomato commented 3 years ago

@tasty0tomato Where were you sourcing your copy from? and how was the version number and date determined?

A copy of he git gui is held and updated within the main Git and Git for Windows projects.

Snipaste_2020-11-28_20-34-53 Snipaste_2020-11-28_20-35-10
PhilipOakley commented 3 years ago

That looks the same as mine.

I'm not sure if there is any policy yet with respect to adjusting the Git Gui version number. The maintenance of the gui has changed since that 2010 copyright date.

tasty0tomato commented 3 years ago

@PhilipOakley So Git Gui in each new git-for-windows is updated actually?

PhilipOakley commented 3 years ago

So Git Gui in each new git-for-windows is updated actually?

Correct. Git for Windows gets it from the upstream Git, which gets it from the modern Git Gui maintainer. I would expect that Pratyush will be having a think about how best to update the GUI's version field in future releases.

tasty0tomato commented 3 years ago

@PhilipOakley Thank you very much! Look forward to v1.0!

PhilipOakley commented 3 years ago

You can look at the history of the git-gui directory within git.git at https://github.com/git/git/commits/master/git-gui

This show plenty of updates, however the last update of the version looks to be way back at Oct 20, 2016.

https://github.com/git/git/commit/3eae3087008f7f2b2a9f7f357d069e9384007c8f#diff-897aa83b2d06735d93ce7872f8472b9c17c3813e5b75dc418559cfed92277090

prati0100 commented 3 years ago

Hi @tasty0tomato,

As of now I don't make releases for Git Gui. Part of the reason is that I just have not bothered to do so, but part of the reason is also that no package manager directly consumes Git Gui from my repo. They do so from the Git or Git for Windows repos. So there is little practical benefit in making releases because a Git or Git for Windows release automatically includes a new Git Gui "release". That said, I am not opposed to making a release in sync with the Git release schedule.

The question is, why do you want a new release? Is consuming the Git Gui updates via the official Git repos not enough? Do you intend to use this repo independently for those two projects?

As for version 1.0, that is just arbitrary. I could release 1.0 today and it would make absolutely no difference at all, neither to the developers nor the users.

PhilipOakley commented 3 years ago

Hi @prati0100

I think that the the issue is that 'users' (inc those who manage software) aren't aware about the software pipeline so don't know that they can trust the 2.29.2.windows.2 version as being folded into the git-gui's effective version.

Folks trust the version string as a stand in for the progress in the development history of whichever piece of software they are reviewing. Most are thinking along the semver numbering lines but usually are at least expecting a change in the version string..

Looking back at the original 0.21.GITGUI release to git.git, that was Junio pulling a tag at that time. Updating the version string for the future may be as simple as adding a tag and a change to the DEF_VER=0.21.GITGUI version string at the point that you ask Junio to pull the latest & greatest.

The tricky bit is to decide how the version string should look, and whether it should have any continuity with the old string, or try and match upstream git's version (e.g. changing to 2.29.0 because it was pulled at the time of the v2.29.0-rc2, and then 2.30.GITGUI, in line with Junio's rel note preparation), and adding a 'patch' release if needed. dunno.

prati0100 commented 3 years ago

@PhilipOakley ok, makes sense. I will start updating the version string from now on.

As for what it will look like, I don't think using Git's version makes a lot of sense. For one, it is a massive jump from 0.21 to 2.30 and people might wonder where 1.0 and rest went. Git Gui is not directly related to any specific Git version. It is supposed to work on all versions. Using Git's version number might give the wrong impression that it is dependent on it.

So the question is if I should use 1.0 or 0.22. I don't really know which is better but maybe it indeed is time for a long overdue 1.0 release. Dunno.

PhilipOakley commented 3 years ago

So the question is if I should use 1.0 or 0.22. I don't really know which is better but maybe it indeed is time for a long overdue 1.0 release. Dunno.

How about adding tags to the commits that Junio pulled in the past, so they'll be 0.22 - 0.35 (or whatever number it reaches).

And then start afresh with DEF_VER=1.0.GITGUI ready for the next release (as part of git.v2.30) which would be tagged the same for Junio, then you could do 1.1, 1.2, 1.3 etc, for Junio's main releases, and say 1.0.1.GITGUI if there was some fix/maintenance release as part of git.v.2.30.1 ... Thoughts?