On 2015-03-31 19:05, Mojca Miklavec wrote:
> On Tue, Mar 31, 2015 at 5:12 PM, Rainer Müller wrote:
>>
>> Futhermore, while we can fix all the Portfiles in the official tree by
>> search and replace, we do not know whether others keep private port
>> trees affected by such changes.
>
> Keep in mind
Hi,
> In my opinion increasing the version of the portgroup should be
> reserved for (fundamentally) incompatible changes or when the syntax
> changes. (For example when switching from qt4 to qt5 if the portgroup
> would initially be just "qt". Or if the python PortGroup would start
> working for
On Tuesday March 31 2015 16:23:47 Lawrence Velázquez wrote:
I'm with Mojca on this.
> > I feel that starting a new revision would introduce way more work than
> > benefits.
Depends on how you look at it. If the new revision had the OOS build activated
by default and from the onset, most maintai
On Mar 31, 2015, at 1:05 PM, Mojca Miklavec wrote:
> In my opinion increasing the version of the portgroup should be
> reserved for (fundamentally) incompatible changes or when the syntax
> changes.
This is just changing the question to "what's an 'incompatible'
change?".
Permitting portgroups
On Mar 31, 2015, at 11:12 AM, Rainer Müller wrote:
> In my opinion, changes to the default behavior of port group options
> should be introduced with an increment of the port group version.
>
> In this case, it would have worked like this:
>
> 1. Add a new port group cmake-1.1.tcl with
> 'def
On Tue, Mar 31, 2015 at 5:12 PM, Rainer Müller wrote:
>
> Futhermore, while we can fix all the Portfiles in the official tree by
> search and replace, we do not know whether others keep private port
> trees affected by such changes.
Keep in mind that private ports that aren't occasionally kept up
Hello,
I'm late to reply to this, but I want to discuss port group updates like
this one in general.
On 2015-03-18 23:28, MacPorts wrote:
> #47197: cmake-based ports: add cmake.out_of_source yes/no
> -+-
> Reporter: mojca@…
