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?
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
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
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
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-- .
&
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.
> 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
> 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
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.
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
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
11 matches
Mail list logo