Changing port group default options

[Rainer Müller]

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 that private ports that aren't occasionally kept up to
> date are sooner or later bound to cause problems in one way or
> another.

Of course, there may always be unresolved problems with external ports
due to incompatible changes. This was just another use case that
benefits from increasing the port group version and not my primary concern.

> Assume that port A depends on B. User creates a private copy of B and
> keeps it outdated. After a while port A could require the latest
> version of B and the users' installation will break both because port
> B will stay at an incompatible version and also because fetching a
> binary archive of A will link against libBsomething.3.dylib, while B
> would provide libBsomething.2.dylib.

I was not necessarily talking about copies of ports in the official
tree, but also ports for software that is not in the official tree yet
or used for internal purposes only.

> 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 software written in C++ with Python bindings.) I agree
> that this kind of change in the cmake PortGroup is almost the
> bordercase, but I feel that starting a new revision would introduce
> way more work than benefits.

Incrementing the minor number should always be possible when adding new
options. In this case, older Portfiles would still be compatible without
any changes to syntax. That is why I suggested to go from version 1.0 to
1.1. Introducing changes with new syntax or completely different
behavior should increase the major version number (i.e. 2.0).

Rainer