Re: `git describe`

2016-11-29 Thread René J . V . Bertin
On Tuesday November 29 2016 16:53:26 Clemens Lang wrote: >reasonably often, since the first answer you'll get when filing a bug against >an >older version of master is 'update to the latest version'. With the risk of trolling: how do you determine whether someone is running an older version?

Re: `git describe`

2016-11-29 Thread Clemens Lang
Hi, - On 29 Nov, 2016, at 14:49, René J.V. Bertin rjvber...@gmail.com wrote: > But doing this you are implicitly > > You shouldn't try to extract information from a x.x.99 version number > > because it will always pass the test in your ports, regardless of whether the > user actually kept

Re: `git describe`

2016-11-29 Thread Rainer Müller
On 2016-11-29 15:01, Davide Liessi wrote: > 2016-11-29 14:49 GMT+01:00 René J.V. Bertin : >> On Tuesday November 29 2016 13:28:27 Clemens Lang wrote: >>> You can just use >>> [vercmp $macports_version 2.3.4] > 0 >>> to check whether a bugfix you need is available. >> >> Which

Re: `git describe`

2016-11-29 Thread René J . V . Bertin
On Tuesday November 29 2016 13:28:27 Clemens Lang wrote: >In which case you're missing the other reason, that is detecting newer MacPorts >versions. I have used this in the past to write and commit a Portfile that >would not work with a released version of MacPorts. Missing only in the sense

Re: `git describe`

2016-11-29 Thread René J . V . Bertin
On Tuesday November 29 2016 03:15:03 Ryan Schmidt wrote: >> Then you have your answer in fact. When you bump the version in that script >> you can use git-release or equivalent to create a 2.4.99 tag, and from there >> on `git describe` would identify master as 2.4.99-- . &

Re: `git describe`

2016-11-29 Thread Ryan Schmidt
you can use git-release or equivalent to create a 2.4.99 tag, and from there > on `git describe` would identify master as 2.4.99-- . > That'd be almost exactly what I'd like to see (though later rather than > sooner). We don't want a x.x.99 tag. It wouldn't mean anything. x.x.99 means master.

Re: `git describe`

2016-11-28 Thread Ryan Schmidt
> On Nov 28, 2016, at 3:28 PM, René J.V. Bertin wrote: > >> As you discovered yourself now, 'port version' of master identifies >> itself as 2.3.99 at the moment. > > Yes, and if you look at the history of the script in config that sets that > version, it apparently has

Re: `git describe`

2016-11-28 Thread Lawrence Velázquez
> On Nov 28, 2016, at 7:41 AM, René J.V. Bertin wrote: > > This is moot if master is exclusively a testing area for experiments > that may never make it to a release. If it has a more usual role and > is used by those who live on the bleeding edge, then my point stands All

Re: `git describe`

2016-11-28 Thread René J . V . Bertin
FWIW, running configure in the current master/head prints "MacPorts version 2.3.99", which complies with common practice I see elsewhere ... except that here it's a hard-coded version. R.

Re: `git describe`

2016-11-28 Thread Rainer Müller
it-release > /opt/local/bin/git-release is provided by: git-extras > > It does change something. Don't ask me the details but the 1 or 2 > times that I've tried to make a release which behaves correctly > w.r.t. git-describe I succeeded with that command, not by creating > the tag m

`git describe`

2016-11-28 Thread René J . V . Bertin
Hi, Git has a very useful feature when tags are used properly, where each commit increases a counter so that the `git describe` command returns the current release version plus a patchlevel. I use this in certain of my KF5 -devel ports but one can also imagine a MacPorts-devel (or -testing