On 29 November 2016 at 19:42, René J.V. Bertin wrote:
> On Tuesday November 29 2016 19:03:04 Clemens Lang wrote:
>
>> By asking. Somebody who wastes developers time by hiding the fact that
>> they are running and older version on purpose will end up no longer
>> getting support at some point.
>
> W
On Tuesday November 29 2016 19:03:04 Clemens Lang wrote:
Since you decided to answer despite the smiley ... :)
> By asking. Somebody who wastes developers time by hiding the fact that
> they are running and older version on purpose will end up no longer
> getting support at some point.
>
> No ne
Hi,
On Tue, Nov 29, 2016 at 05:17:18PM +0100, René J.V. Bertin wrote:
> With the risk of trolling: how do you determine whether someone is
> running an older version? ;)
By asking. Somebody who wastes developers time by hiding the fact that
they are running and older version on purpose will end u
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 th
work; more often than not dch will tell you that the new shorthash isn't newer
than the old shorthash.
If you want to use this kind of scheme linking it to a specific commit without
using `git describe` you could do x.y.99-[YY]YYMMDDhhmm[ss] . That's not longer
than adding the short
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 will always succeed i
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 will always succeed if you're using a MacPorts base built from master,
On 2016-11-29 13:28, Clemens Lang wrote:
> You shouldn't try to extract information from a x.x.99 version number, so no,
> no
> such synchronization is required. You can just use
> [vercmp $macports_version 2.3.4] > 0
> to check whether a bugfix you need is available.
In the past, we often just
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 that
- On 29 Nov, 2016, at 12:14, René J.V. Bertin rjvber...@gmail.com wrote:
> Right now I can only think of 1 important reason why Portfiles might want to
> check for the MacPorts version, and that's to detect older MacPorts versions.
In which case you're missing the other reason, that is dete
>From the ChangeLog
>- Added macports_version to the Portfile execution context, to allow
> checking the current MacPorts version in Portfiles.
> (cal in r134511)
Right now I can only think of 1 important reason why Portfiles might want to
check for the MacPorts version, and that
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-- .
&
.3.99 after we created the 2.3 release branch, which was
>> 2 years ago. After we create a 2.4 release branch, the version on master
>> will be changed to 2.4.99.
>
> Then you have your answer in fact. When you bump the version in that script
> you can use git-release or e
se branch, the version on master will be
>changed to 2.4.99.
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-- . That'd
be almost ex
> 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 been fixed at 2.3.99 fo
g a commit hash
>to 'port version'. You put out a question about 'git describe', but
>apparently you did not even look up or understood what it does or how it
>works.
I didn't investigate exactly how it works, but I do know it's based on
annotaged tags, and of c
e context of a MacPorts-devel port which could cater to users who'd
> like to follow the "base" development version but not necessarily the
> real bleeding edge. Presuming the MacPorts port is used to create the
> official installers: a -devel version could create snapshots
> 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 development is done on
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.
On Monday November 28 2016 12:54:35 Rainer Müller wrote:
> The release was done from the release-2.3 branch, which has diverged
> from the master branch. There is no way to merge either branch to the
> other. I do not see any importance in getting this tag to the master branch.
>
> Fact is, maste
d, master contains many
commits that were only partially cherry-picked to the release-2.3 branch.
>> I don't see how that would change anything for 'git describe', if
>> this is only done on a branch.
>
> I guess we'd have to understand exactly what `git descr
.
What I don't know is how you'd apply the tag to the branch too. Presumably not
by merging master back into the branch after creating the release tag, because
apparently that doesn't work the other way either.
> I don't see how that would change anything for 'git d
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
>
/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 manually. IIRC it had
something to do wit
On 2016-11-28 10:18, René J.V. Bertin wrote:
> 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
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 or
27 matches
Mail list logo
