Getting to 1.4.1.

[James Berry]

Hi Jordan,

On Apr 14, 2007, at 1:39 AM, Jordan K. Hubbard wrote:

> 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. :-)

Well, I'm about one svn merge command from where you are.

In creating the 1.4.1 tag last night, all I did was an svn merge of  
trunk to release_1_4 branch, and then tagged 1.4.1. So while I had to  
type one one more command, we also "buy" the freedom to have the two  
diverge more in the future if necessary. Granted, there are other  
ways to achieve that, but this seemed a relatively cheap price to pay.

James


>
> - 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
>