Getting to 1.4.1.

[Paul Guyot]

On Apr 14, 2007, at 11:10 AM, James Berry wrote:

> In an effort to expedite small releases of MacPorts, such as 1.4.1,  
> I'd like to suggest that we keep trunk as usable as possible,  
> whenever we can.
>
> As an example, it's been suggested that the universal variant  
> support in trunk is relatively immature, while most of the other  
> changes in trunk would be ready for release. May I suggest that we  
> put in ./configure --with-universal-variant or a ports.conf setting  
> to to disable the effect of that variant? This would achieve two  
> things, I believe:
>
> 	* Remove the threat of this option from trunk, while still  
> allowing development and testing of the feature to continue on trunk.
> 	* Allow easy merging/tagging of 1.4.1 based on a complete merge  
> from trunk.

James,

Thank you for managing the 1.4.1 release.
I do not understand why the universal variant support in trunk is  
immature, and more importantly, what the plan is to make it more  
mature. I do not see the advantage of disabling it by default either.  
The code was designed to have strictly no incidence or to induce no  
behavior change as long as users do not select the variant +universal  
to build a port.

As far as the next releases are concerned, I would like to see the  
following features (from trunk) becoming public, in order to be able  
to benefit from them in portfiles:
- universal variant code
- configure flags (we'll be able to clean *many* ports)
- ignore ssl certificate when fetching (will fix a port that requires  
this option)
- new livecheck options

I would like to stress that if the configure flags code isn't  
released soon, maintainers who often use trunk might check in code  
that will not work for users who often use release, if this hasn't  
happened yet. Indeed, the trunk configure flags code provides -I$ 
{prefix}/include and -L${prefix}/lib in CPPFLAGS by default, and some  
software require that.

Paul