Getting to 1.4.1.

[Jordan K. Hubbard]

I'm still waiting for a convincing explanation as to why simply  
tagging trunk and calling it 1.5 (vs 1.4.1) wouldn't be a perfectly  
viable solution and way less pain than merging stuff over.   I haven't  
heard one yet. :-)

- Jordan

On Apr 13, 2007, at 7:25 PM, Paul Guyot wrote:

>
> 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
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev