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. In general, this should allow us to quickly/easily tag minor revs so that we can keep up the pace of development and innovation. Thoughts? James
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
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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
On Apr 14, 2007, at 5:58 AM, James Berry wrote:
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.
And I've always defended that "freedom to diverge", I just propose doing it a different way, namely creating branches off trunk for the truly risky stuff and leaving trunk still more or less "stable" (but progressive) at any given time. - Jordan
participants (3)
-
James Berry
-
Jordan K. Hubbard
-
Paul Guyot